Just to throw this out there, is this something we need for Icehouse?
Yes, I fully acknowledge that it's an ugly security hole. But what's our
story for how stable/clean Tuskar will be for Icehouse? I don't believe
the intention is for people to use this in a production environment yet,
so it will be people trying things out in a test environment. I don't
think it's absurd to document that we haven't finished hardening the
security yet and to not use super-sensitive passwords.
If there was a simple answer, I likely wouldn't even suggest this. But
there's some real design and thought that needs to take place and,
frankly, we're running out of time. Keeping in mind the intended usage
of the Icehouse release of Tuskar, it might make sense to shelve this
for now and file a big fat bug that we address in Juno.
On 02/20/2014 08:47 AM, Radomir Dopieralski wrote:
On 20/02/14 14:10, Jiří Stránský wrote:
On 20.2.2014 12:18, Radomir Dopieralski wrote:
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.
I don't think it would damage the user experience so much. All you need
is an additional configuration option in Tuskar-UI and Tuskar-client,
the encryption key.
That key would be used to encrypt the passwords when they are first sent
to Tuskar-API, and also added to the (re)deployment calls.
This way, if the database leaks due to a security hole in MySQL or bad
engineering practices administering the database, the passwords are
still inaccessible. To get them, the attacker would need to get
*both* the database and the config files from host on which Tuskar-UI runs.
With the tuskar-client it's a little bit more obnoxious, because you
would need to configure it on every host from which you want to use it,
but you already need to do some configuration to point it at the
tuskar-api and authenticate it, so it's not so bad.
I agree that this complicates the whole process a little, and adds
another potential failure point though.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
