On 12/17/2010 09:57 AM, Dmitri Pal wrote:
> On the a) and b) cases the sequence will probably eventually be more > complex. The secret passed on the image launch will be used to identify > the system and authenticate to the rendezvous point. I see it bing an > OTP that would allow the machine to acquire keytab and authenticate > against the cloud infrastructure auth server (IPA). This authentication > in turn would allow Matahari to connect and get CDL. I do not think it > is wise to allow anyone to get CDL without authentication but for the > proto the simplified approach will do. I also think that it makes sense > to run a special instance of IPA for the VMs in the publick cloud to > have a better separation of duties between the IPA that will serve the > bootstraping of the VMs in the public cloud and the IPA that will be > serving identities for the cloud infrastructure. The CDL downloaded by > Matahari will have another secret that would allow the machine to get on > the VPN and connect to the corporate environment. At this moment > Matahari will reinitialize itself and connect to the internal > infrastructure . We can also add some VPN remediation work later on to > handle patching and security audit of the machine connecting to the > network but this can be viewed as a separate task and can be deferred.
Multiple levels of security can be configured here. First we can secure the communication and the domain, with AMQP. The reason for the secrete is to prevent someone compromising one machine and updating the status of the remote cache. This way they only have w access to one item in the cache based on the secrete. Following OAuth 2 way that bk forwarded to me.
I believe securing the initial channel needs some discussion, as there are a few options but I see that separate but related to this process.
> As for c) I really think we should just ask the cloud vendor to fix the > interface to allow passing data to the image at launch time. By the time > we are ready they might already fix it. Not having a way to pass > information at launch time is the limitation that not only us would be > complaining about. For a time being we can create a different starter > image dynamically by seeding it with appropriate information but I do > not think we should spend a lot of time trying to solve this use case. > Have we already logged an RFE with GoGrid?
Agree, that is why I stopped on the impl of this option. Carl.
