Open Stack

On 02/19/2014 06:10 PM, Ladislav Smola wrote:
> Hello,
>
> I would like to have your opinion about how to deal with passwords in
> Tuskar-API
>
> The background is, that tuskarAPI is storing heat template parameters in
> its database, it's a
> preparation for more complex workflows, when we will need to store the
> data before the actual
> heat stack-create.
>
> So right now, the state is unacceptable, we are storing sensitive
> data(all the heat passwords and keys)
> in a raw form in the TuskarAPI database. That is wrong right?

Right, that is definitely wrong.

> So is anybody aware of the reasons, why we would need to store the
> passwords? Storing them
> for a small amount of time (rather in a session) should be fine, so we
> can use them for latter init of the stack.
> Do we need to store them for heat stack-update? Cause heat throws them away.

You will need those passwords after Heat finished creating the stack and 
Tuskar is going to initialize Keystone and register the services. 
Keystone can't be used for that because a) Tuskar will need the 
password, not a token, b) Keystone is not yet initialized.
Since stack creation is an asynchronous operation, the session might 
have gone long time ago. So storing it in the session would not work, 
Tuskar has to store it in a more permanent place.

You will also need the password every time a service need reregistered. 
Eg. user decides to get rid of swift, then changes his mind, but can't 
undo the operation because the password is gone.

> If yes, this bug should change to encrypting of the all sensitive data,
> right? Cause it might be just me,
> but dealing with sensitive data like this the 8th deadly sin.
>
> The second thing is, if users will update their passwords, info in the
> TuskarAPI will be obsolete and
> can't be used anyway.

I don't think that the user is going to change the password for 
different services. We should also investigate if the service will work 
after someone changes its password.

I don't see any problem in storing passwords for the overcloud, since 
Tuskar *is* the management interface. But I agree, we should do it more 
securely.

Imre

>
> There is a bug filled for it:
> https://bugs.launchpad.net/tuskar/+bug/1282066
>
> Thanks for the feedback, seems like the bug is not as straightforward as
> I thought.
>
> Kind Regards,
> Ladislav