OCF inter-federation model was initially thought only for federation of OCF clients, but RMs has been extended to support GENIv2 and SFA clients -- and GENIv3 may come soon.
However, the problem with these new APIs is how to authenticate users into the RM resources (e.g. VMs).
Current status
We use specific images for federated users:
Legacy: simple image with default user and password
Default Federated (in progress): default image with PAM modules authenticating against a different "Federation LDAP"
Problems
This approach is OK for first implementation, but it poses a number of problems:
Legacy: not secure
Default Federated (in progress): not scalable, since we should offer access to both ocf and a federated LDAPs
Also, the images have specific extensions: .tar.gz and .img. Whilst the former could be done by modifying the image on-the-fly (which we already do and implies a significant lack of performance on the time of the VM creation, which is obtained through paravirtualization), the latter cannot be modified (at least in the same way). In any case, we should avoid modifications on-the-fly.
Alternatives
A possible solution would be to use some kind of contextualization API that allows to pass/embed scripts at boot time independently of the image type or distribution. This way we could use any approach to let federated users authenticate to the VMs (e.g. passing user or slice public keys, etc).
Apparently, XEN 4 API does not allow contextualization. We should evaluate if XEN Server 6 provides any API to do this. Otherwise, we should seriously evaluate the use of Open Nebula, CloudStack, OpenStack or similar; despite having a hard installation, configuration and integration processes.
We could also take the chance to get rid of the Linux bridges and use OpenVSwitch or similar to guarantee isolation between slices for the users, if possible.
CarolinaFernandez
commented
9 years ago
OCF inter-federation model was initially thought only for federation of OCF clients, but RMs has been extended to support GENIv2 and SFA clients -- and GENIv3 may come soon.
However, the problem with these new APIs is how to authenticate users into the RM resources (e.g. VMs).
Current status
We use specific images for federated users:
Problems
This approach is OK for first implementation, but it poses a number of problems:
Also, the images have specific extensions:
.tar.gzand.img. Whilst the former could be done by modifying the image on-the-fly (which we already do and implies a significant lack of performance on the time of the VM creation, which is obtained through paravirtualization), the latter cannot be modified (at least in the same way). In any case, we should avoid modifications on-the-fly.Alternatives
A possible solution would be to use some kind of contextualization API that allows to pass/embed scripts at boot time independently of the image type or distribution. This way we could use any approach to let federated users authenticate to the VMs (e.g. passing user or slice public keys, etc).
Apparently, XEN 4 API does not allow contextualization. We should evaluate if XEN Server 6 provides any API to do this. Otherwise, we should seriously evaluate the use of Open Nebula, CloudStack, OpenStack or similar; despite having a hard installation, configuration and integration processes.
We could also take the chance to get rid of the Linux bridges and use OpenVSwitch or similar to guarantee isolation between slices for the users, if possible.