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 ?

Mario 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.

Víctor comment:

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.

More ideas ? comments ?