[openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

Tomas Sedovic tsedovic at redhat.com
Thu Feb 20 13:33:23 UTC 2014


On 20/02/14 14:10, Jiří Stránský wrote:
> 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.

This to me reads as: we should fix the OpenStack services not to store
passwords in their service.conf, not making the situation worse by
storing them in even more places.

> 
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 




More information about the OpenStack-dev mailing list