Open Stack

On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
> For what it's worth in Sahara (former Savanna) we inject the second
> key by userdata. I.e. we add
> echo "${public_key}" >> ${user_home}/.ssh/authorized_keys
>
> to the other stuff we do in userdata.
>
> Dmitry
>
> 2014-03-10 17:10 GMT+04:00 Jiří Stránský <jistr at redhat.com>:
>> On 7.3.2014 14:50, Imre Farkas wrote:
>>> On 03/07/2014 10:30 AM, Jiří Stránský wrote:
>>>> Hi,
>>>>
>>>> there's one step in cloud initialization that is performed over SSH --
>>>> calling "keystone-manage pki_setup". Here's the relevant code in
>>>> keystone-init [1], here's a review for moving the functionality to
>>>> os-cloud-config [2].

You really should not be doing this.  I should never have written 
pki_setup:  it is a developers tool:  user a real CA and a real certificate.

>>>>
>>>> The consequence of this is that Tuskar will need passwordless ssh key to
>>>> access overcloud controller. I consider this suboptimal for two reasons:
>>>>
>>>> * It creates another security concern.
>>>>
>>>> * AFAIK nova is only capable of injecting one public SSH key into
>>>> authorized_keys on the deployed machine, which means we can either give
>>>> it Tuskar's public key and allow Tuskar to initialize overcloud, or we
>>>> can give it admin's custom public key and allow admin to ssh into
>>>> overcloud, but not both. (Please correct me if i'm mistaken.) We could
>>>> probably work around this issue by having Tuskar do the user key
>>>> injection as part of os-cloud-config, but it's a bit clumsy.
>>>>
>>>>
>>>> This goes outside the scope of my current knowledge, i'm hoping someone
>>>> knows the answer: Could pki_setup be run by combining powers of Heat and
>>>> os-config-refresh? (I presume there's some reason why we're not doing
>>>> this already.) I think it would help us a good bit if we could avoid
>>>> having to SSH from Tuskar to overcloud.
>>>
>>> Yeah, it came up a couple times on the list. The current solution is
>>> because if you have an HA setup, the nodes can't decide on its own,
>>> which one should run pki_setup.
>>> Robert described this topic and why it needs to be initialized
>>> externally during a weekly meeting in last December. Check the topic
>>> 'After heat stack-create init operations (lsmola)':
>>>
>>> http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html
>>
>> Thanks for the reply Imre. Yeah i vaguely remember that meeting :)
>>
>> I guess to do HA init we'd need to pick one of the controllers and run the
>> init just there (set some parameter that would then be recognized by
>> os-refresh-config). I couldn't find if Heat can do something like this on
>> it's own, probably we'd need to deploy one of the controller nodes with
>> different parameter set, which feels a bit weird.
>>
>> Hmm so unless someone comes up with something groundbreaking, we'll probably
>> keep doing what we're doing. Having the ability to inject multiple keys to
>> instances [1] would help us get rid of the Tuskar vs. admin key issue i
>> mentioned in the initial e-mail. We might try asking a fellow Nova developer
>> to help us out here.
>>
>>
>> Jirka
>>
>> [1] https://bugs.launchpad.net/nova/+bug/917850
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev