On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote:
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
I have not been following this thread nor I do I know or understand all
your requirements but I wanted to bring to your attention the fact
OpenStack has a project called Barbican whose primary purpose is to
safely store keys, plus it has many other features for handling keys.
Key handling is tricky so rather than try to design something yourself
perhaps it might make sense to leverage the Barbican work.
https://wiki.openstack.org/wiki/Barbican/Incubation
http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/
http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack
--
John
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
