[openstack-dev] [TripleO] os-cloud-config ssh access to cloud
james.slagle at gmail.com
Mon Mar 10 20:39:50 UTC 2014
On Mon, Mar 10, 2014 at 6:10 AM, Jiří Stránský <jistr at redhat.com> wrote:
> On 7.3.2014 14:50, Imre Farkas wrote:
>> On 03/07/2014 10:30 AM, Jiří Stránský wrote:
>>> 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 , here's a review for moving the functionality to
>>> os-cloud-config .
>>> 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)':
> 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.
Agreed, I think what you've done here is fine.
As you keep churning through init-keystone, keep in mind that there
are some recent changes in review that switch that script over to
use openstack-client instead of keystoneclient. That was needed due to
the required use of the keystone v3 api to create a domain for the
heat stack user. A fallback backwards compatibility was added to Heat
to allow the existing behavior to still work, but I don't see a reason
for you to reimplement the old way of doings things in
os-cloud-config. There is a helper script in Heat that shows how
the domain should be created.
> Having the ability to inject multiple keys to
> instances  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.
>  https://bugs.launchpad.net/nova/+bug/917850
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-- James Slagle
More information about the OpenStack-dev