Open Stack

On 21/02/14 10:38, Dougal Matthews wrote:
> On 21/02/14 09:24, Tomas Sedovic wrote:
>> On 20/02/14 16:24, Imre Farkas wrote:
>>> 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.
>>
>> Well if that is the case and we can't change the templates/heat to
>> change that, the secrets should be put in Keystone or at least go
>> through Keystone. Or use Barbican or whatever.
>>
>> We shouldn't be implementing crypto in Tuskar.
> 
> +1, after giving this quite a bit of thought i completely agree. This
> is really out of the scope of Tuskar. I think we should definitely go
> down this route and only fall back to storing all these details
> later, that could be an improvement if it turns out to be a real
> usability problem.
> 
> At the moment we are guessing, we don't even know how many passwords
> we need to store. So we should progress with the safest and simplest
> option (which is to not store them) and consider changing this later.

I think we have a pretty good idea:
https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overcloud/workflows/undeployed_configuration.py#L23-L222

(just count the "NoEcho": "true" lines)
-- 
Radomir Dopieralski