Open Stack

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.
>