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

Imre Farkas ifarkas at redhat.com
Mon Feb 24 09:20:07 UTC 2014


On 02/24/2014 09:39 AM, Ladislav Smola wrote:
> On 02/23/2014 01:16 AM, Clint Byrum wrote:
>> Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +0000:
>>> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
>>>> On 20/02/14 15:41, Radomir Dopieralski wrote:
>>>>> On 20/02/14 15:00, Tomas Sedovic wrote:
>>>>>
>>>>>> Are we even sure we need to store the passwords in the first
>>>>>> place? All
>>>>>> this encryption talk seems very premature to me.
>>>>> How are you going to redeploy without them?
>>>>>
>>>> What do you mean by redeploy?
>>>>
>>>> 1. Deploy a brand new overcloud, overwriting the old one
>>>> 2. Updating the services in the existing overcloud (i.e. image updates)
>>>> 3. Adding new machines to the existing overcloud
>>>> 4. Autoscaling
>>>> 5. Something else
>>>> 6. All of the above
>>>>
>>>> I'd guess each of these have different password workflow requirements.
>>> I am not sure if all these use cases have different password
>>> requirement. If you check devtest, no matter whether you are creating or
>>> just updating your overcloud, all the parameters have to be provided for
>>> the heat template:
>>> https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125
>>>
>>>
>>> I would rather not require the user to enter 5/10/15 different passwords
>>> every time Tuskar updates the stack. I think it's much better to
>>> autogenerate the passwords for the first time, provide an option to
>>> override them, then save and encrypt them in Tuskar. So +1 for designing
>>> a proper system for storing the passwords.
>> Tuskar does not need to reinvent this.
>>
>> Use OS::Heat::RandomString in the templates.
>>
>> If any of them need to be exposed to the user, use an output on the
>> template.
>>
>> If they need to be regenerated, you can pass a "salt" parameter.
>
> Do we actually need to expose to the user something else than
> AdminPassword?

I think we should not. The MySQL password or any of the service 
passwords are "implementation details" of the cloud, it should not be 
used by anyone, except for OpenStack internally. The administrator 
should setup separate user accounts with the proper privileges to access 
these services.

Imre

> We are using tripleo-heat-templates currently, so we will need to make
> the change
> there.




More information about the OpenStack-dev mailing list