incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Pal <d...@redhat.com>
Subject Re: Initial boot / post boot Matahari cloud agent and Deltacloud interactions
Date Fri, 17 Dec 2010 16:29:53 GMT
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/


Mime
View raw message