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

Clint Byrum clint at fewbar.com
Sun Feb 23 00:16:10 UTC 2014


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.



More information about the OpenStack-dev mailing list