-
Notifications
You must be signed in to change notification settings - Fork 25
RFC #1: Renewal proxy for the VMs instead of a cert (pub,key)
This is a request for comments about the next generation security method in the Virtual Machines. The aim is to avoid the risk of put a private key certificate in the VMs, even when this keys are in private images or secured copy to a VMs. A more secure aproach would be to use a X509 temporal proxy, for the nature of such method the secure copy would be the method to put it in the VMs. The DIRAC proxy manager Agent could be used to renewal the VMs proxies when close to expire. The secure aproach is to put all the control of the renewal in the DIRAC server side, so a initially a ssh access is necesary to copy the proxy. Unfortunally this method is not allways suported by IaaS providers. Ideas ? Comments ?
I agree with you hostcert + hostkey on the VM is not the best. And I do not like passing the "secret" on the contextualization step. Thinking a bit I found few things I did not get, plus few other thoughts.
Proxies make a lot of sense since they have a limited duration, which makes very useful in two main scenarios: a) wrong permissions, so that any can read the proxy b) man-in-the-middle attack
no matter what, if they get stolen / lost, they will expire within a short period of time.
On the other hand, we have the certificates. If they get stolen, they are valid for a long time. However, which permissions should have those certificates / proxies ? Given the environment where they run, their permissions should be very restrictive ( or our Services methods... ).
After all, we want something to get our agents running on the VM ( either a proxy or a certificate ): note that I'm leaving aside on purpose the technical details of doing the communication with a proxy and the roles it should have.
If we use the "ssh contextualization", we go directly from a trusted machine to the VM. Then I wonder, why should we use a proxy on this scenario ( neither a) nor b) apply ) ? On the other hand, if we do not use contextualization, we rely on the Cloud provider security.
Lastly, "ssh contextualization": I must admit I'm not a big fan of it, and as you said, sometimes it is simply not an option.
I see interesting the posibility you've mentioned about trusted machine scenario without proxy, but a proxy can be banned from VOMS while trusted machine relays all the machinery on DIRAC. Additionally it would be the technical question of how to trust a machine that eventually can have a private IP.
You seem to propose to use a proxy and the DIRAC proxy manager service to renew the proxy when needed. If this is not the case, do not read any further.
This is not possible. From a security point of view it is not allowed that a given credential can extend it self. How it is working on the GRID is that WMS servers are "trusted" hosts of the MyProxy and request a new proxy for the given user validated by their owned certificate (the certificate of the WMS server).
For me the running VM is a closed and secure system, thus I see no problem to install a host certificate once the VM has been started (certainly not in the image, but as part of the contextualization).
What remains to be decided if we used a pull or a push model.
The main problem I see with a push model is that it is not guaranteed that one will have inbound connectivity to all VMs, so in principle I would be inclined for pull mechanism in which a valid credential is given to the VM during the contextualization phase and this credential is used then by the machine to get/update a proper credential for the execution of the JobAgents,.... We can certainly limit the operations that the bootstrap credential can do, and even only accept the requests if they present some extra "token" like the unique ID of the VM that has be made know to DIRAC by other means or some other Unique identifier that it is associated to the VM.
If in any case a push model is preferred I would suggest to include in the contextualization procedure a "dummy" credential that allows to declare the VM running and opens a listening service to which a DIRAC component can connect, after the "running" message has been received and validated, to upload the real credential and start the VMMonitoring and JobAgent.