Open Stack

Hi folks.

Today I want to discuss the way we save SSL keys for Fuel environments. As
you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in this
case). In this case we will generate private key, csr and crt in a
pre-deployment hook on master node and then copy keypair to the nodes which
needed it.

b. Get a pre-generated keypair from user. In this case user should create
keypair by himself and then upload it through Fuel UI settings tab. In this
case keypair will be saved in nailgun database and then will serialized
into astute.yaml on cluster nodes, pulled from it by puppet and saved into
a file.

Second way has some flaws:
1. We already have some keys for nodes and we store them on master node.
Store keys in different places is bad, cause:
1.1. User experience - user should remember that in some cases keys will be
store in FS and in some other cases - in DB.
1.2. It brings problems for implementation in other different places - for
example, we need to get certificate for properly run OSTF tests and now we
should implement two different ways to deliver that certificate to OSTF
container. The same for fuel-cli - we should somehow get certificate from
DB and place it in FS to use it.
2. astute.yaml is similar for all nodes. Not all of nodes needs to have
private key, but now we cannot control this.
3. If keypair data serializes into astute.yaml it means than that data
automatically will be fetched when diagnostic snapshot will created. So in
some cases in can lead to security vulnerability, or we will must to write
another crutch to cut it out of diagnostic snapshot.


So I propose to get rid of saving keypair in nailgun database and implement
a way to always saving it to local FS on master node. We need to implement
next items:

- Change UI logic that saving keypair into DB to logic that will save it to
local FS
- Implement according fixes in fuel-library
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150821/60056946/attachment.html>