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.
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
