Hi John, I agree, that we didn't have these problems if we used Barbican and looks like it's a good tool for our needs. But since we are in Hard Code Freeze we should fix it somehow without introducing big changes in our current architecture.
But it would be a nice to see it as an improvement in 8.0 release. Thanks, On Mon, Aug 24, 2015 at 3:57 PM, John Dennis <jden...@redhat.com> wrote: > 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 >
__________________________________________________________________________ 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