Open Stack

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.

Dougal