Carl Trieloff wrote: > 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 hope you are not planning to build everything around OAuth. > > 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. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
