Excerpts from Adam Young's message of 2014-03-12 06:19:47 -0700:
> 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ý <ji...@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.
>
Thanks!
https://review.openstack.org/80819
> >
> > 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.
>
I recommend we aim for less fist shaking and beating of all kinds in
OpenStack.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
