[openstack-dev] [TripleO] os-cloud-config ssh access to cloud

Adam Young ayoung at redhat.com
Wed Mar 12 13:19:47 UTC 2014


On 03/11/2014 01:20 PM, Clint Byrum wrote:
> Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:
>> 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.
>>
> This alludes to your point, but also says that keystone-manage can be used:
>
> http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki
Yep.  And we need to get a better story for certificate management.
>
> Seems that some time should be spent making this more clear if for some
> reason pki_setup is weak for production use cases. My brief analysis
> of the code says that the weakness is that the CA should generally be
> kept apart from the CSR's so that a compromise of a node does not lead
> to an attacker being able to generate their own keystone service. This
> seems like a low probability attack vector, as compromise of the keystone
> machines also means write access to the token backend, and thus no need
> to generate ones' own tokens (you can just steal all the existing tokens).

This is a pretty good explanation.  I would love to see it submitted as 
part of the keystone configuration document above.

>
> I'd like to see it called out in the section above though, so that
> users can know what risk their accepting when they use what looks like a
> recommended tool. Another thing would be to log copious warnings when
> pki_setup is run that it is not for production usage. That should be
> sufficient to scare some diligent deployers into reading the docs closely
> and mitigating the risk.
Very good idea.

>
> Anyway, shaking fist at users and devs in -dev for using tools in the
> documentation probably _isn't_ going to convince anyone to spend more
> time setting up PKI tokens.

The only one I am shaking my fist at is myself...and maybe those that 
browbeat me into writing the utility.

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list