On 20.2.2014 12:18, Radomir Dopieralski wrote:
On 20/02/14 12:02, Radomir Dopieralski wrote:
Anybody who gets access to Tuskar-API gets the
passwords, whether we encrypt them or not. Anybody who doesn't have
access to Tuskar-API doesn't get the passwords, whether we encrypt
them or not.
Yeah, i think so too.
Thinking about it some more, all the uses of the passwords come as a
result of an action initiated by the user either by tuskar-ui, or by
the tuskar command-line client. So maybe we could put the key in their
configuration and send it with the request to (re)deploy. Tuskar-API
would still need to keep it for the duration of deployment (to register
the services at the end), but that's it.
This would be possible, but it would damage the user experience quite a
bit. Afaik other deployment tools solve password storage the same way we
do now.
Imho keeping the passwords the way we do now is not among the biggest
OpenStack security risks. I think we can make the assumption that
undercloud will not be publicly accessible, so a potential external
attacker would have to first gain network access to the undercloud
machines and only then they can start trying to exploit Tuskar API to
hand out the passwords. Overcloud services (which are meant to be
publicly accessible) have their service passwords accessible in
plaintext, e.g. in nova.conf you'll find nova password and neutron
password -- i think this is comparatively greater security risk.
So if we can come up with a solution where the benefits outweigh the
drawbacks and it makes sense in broader view at OpenStack security, we
should go for it, but so far i'm not convinced there is such a solution.
Just my 2 cents :)
Jirka
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
