Open Stack

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 <jdennis at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/c42151c6/attachment.html>