Open Stack

On 20/02/14 10:12, Radomir Dopieralski wrote:
> On 19/02/14 18:29, Dougal Matthews wrote:
>> The question for me, is what passwords will we have and when do we need
>> them? Are any of the passwords required long term.
> 
> We will need whatever the Heat template needs to generate all the
> configuration files. That includes passwords for all services that are
> going to be configured, such as, for example, Swift or MySQL.


This is a one-time operation, though, isn't it? You pass those
parameters to Heat when you run stack-create. Heat and os-*-config will
handle the rest.

> 
> I'm not sure about the exact mechanisms in Heat, but I would guess that
> we will need all the parameters, including passwords, when the templates
> are re-generated. We could probably generate new passwords every time,
> though.

What do you mean by regenarating the templates? Do you mean when we want
to update the deployment (e.g. using heat stack-update)?

> 
>> If we do need to store passwords it becomes a somewhat thorny issue, how
>> does Tuskar know what a password is? If this is flagged up by the
>> UI/client then we are relying on the user to tell us which isn't wise.
> 
> All the template parameters that are passwords are marked in the Heat
> parameter list that we get from it as "NoEcho": "true", so we do have an
> idea about which parts are sensitive.
> 

If at all possible, we should not store any passwords or keys whatsoever.

We may have to pass them through from the user to an API (and then
promptly forget them) or possible hold onto them for a little while (in
RAM) but never persisting them anywhere.

Let's go through the specific cases where we do handle passwords and
what to do with them.

Looking at devtest, I can see two places where the user deals with
passwords:

http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html

1) in the step 10. (Deploy an overcloud) we pass the various overcloud
service passwords and keys to Heat (it's things like the Keystone Admin
Token & password, SSL key & cert, nova/heat/cinder/glance service
passwords, etc.).

I'm assuming this could include any database and AMQP passwords in the
future.

2) step 17 & 18 (Perform admin setup of your overcloud) where pass some
of the same passwords to Keystone to set up the Overcloud OpenStack
services (compute, metering, orchestration, etc.)

And that's it.

I'd love if we could eventually push the steps 17 & 18 into our Heat
templates, it's where they belong I think (please correct me if that's
wrong).

Regardless, all the passwords here are user-specified. When you install
OpenStack, you have to come up with a bunch of passwords up front and
use them to set the various services up.

Now Tuskar serves as an intermediary. It should ask for these passwords
and then perform the steps you'd otherwise do manually and then *forget*
the passwords again.

Since we're using the passwords in 2 steps (10 and 17), we can't just
pass them to Heat and immediately forget them. But we can pass them in
step 10, wait for it to finish, pass them to step 17 and forget them then.

So here's the workflow:

1. The user wants to deploy the overcloud through the UI
2. They're asked to fill in all the necessary information (including the
passwords) -- or we autogenerate it which doesn't change anything
3. Tuskar UI sends a request to Tuskar API including the passwords
3.1. Tuskar UI forgets the passwords (this isn't an explicit action, we
don't store them anywhere)
4. Tuskar API fetches/builds the correct Heat template
5. Tuskar API calls heat stack-create and passes in all the params
(including passwords)
6. Tuskar API waits for heat stack-create to finish
7. Tuskar API issues a bunch of keystone calls to set up the services
(with the specified passwords)
8. Tuskar API forgets the passwords

The asynchronous nature of Heat stack-create may make this a bit more
difficult but the point should still stand -- we should not persist the
passwords. We may have to store them somewhere for a short duration, but
not throughout the entire lifecycle of the overcloud.

I'm not sure if we have to pass the unchanged parameters to Heat again
during stack-update (they may or may not be stored on the metadata
server). If we do, I'd vote we ask the user to re-enter them instead of
storing them somewhere.