Open Stack

https://blueprints.launchpad.net/nova/+spec/instance-users

Please see the above spec. Nova, Keystone and Barbican have been working together on it this cycle and are hoping to implement it in Mitaka

The problem of secrets from the secret store is not isolated to just Magnum.

Thanks,
Kevin
________________________________________
From: John Dennis [jdennis at redhat.com]
Sent: Tuesday, September 01, 2015 10:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
>
>> The reason that is compelling is that you can have Barbican generate,
>> sign, and store a keypair without transmitting the private key over the
>> network to the client that originates the signing request. It can be
>> directly stored, and made available only to the clients that need access
>> to it.
>
> This is absolutely _not_ how PKI for TLS is supposed to work, yes Barbican
> can create keypairs etc because sometimes that¹s useful but in the
> public-private PKI model that TLS expects this is completely wrong. Magnum
> nodes should be creating their own private key and CSR and submitting them
> to some CA for signing.
>
> Now this gets messy because you probably don¹t want to push keystone
> credentials onto each node (that they would use to communicate with
> Barbican).
>
> I¹m a bit conflicted writing this next bit because I¹m not particularly
> familiar with the Kubernetes/Magnum architectures and also because I¹m one
> of the core developers for Anchor but here goesŠ.
>
> Have you considered using Anchor for this? It¹s a pretty lightweight
> ephemeral CA that is built to work well in small PKI communities (like a
> Kubernetes cluster) you can configure multiple methods for authentication
> and build pretty simple validation rules for deciding if a host should be
> given a certificate. Anchor is built to provide short-lifetime
> certificates where each node re-requests a certificate typically every
> 12-24 hours, this has some really nice properties like ³passive
> revocation² (Think revocation that actually works) and strong ways to
> enforce issuing logic on a per host basis.
>
> Anchor or not, I¹d like to talk to you more about how you¹re attempting to
> secure Magnum - I think it¹s an extremely interesting project that I¹d
> like to help out with.
>
> -Rob
> (Security Project PTL / Anchor flunkie)

Let's not reinvent the wheel. I can't comment on what Magnum is doing
but I do know the members of the Barbican project are PKI experts and
understand CSR's, key escrow, revocation, etc. Some of the design work
is being done by engineers who currently contribute to products in use
by the Dept. of Defense, an agency that takes their PKI infrastructure
very seriously. They also have been involved with Keystone. I work with
these engineers on a regular basis.

The Barbican blueprint states:

Barbican supports full lifecycle management including provisioning,
expiration, reporting, etc. A plugin system allows for multiple
certificate authority support (including public and private CAs).

Perhaps Anchor would be a great candidate for a Barbican plugin.

What I don't want to see is spinning our wheels, going backward, or
inventing one-off solutions to a very demanding and complex problem
space. There have been way too many one-off solutions in the past, we
want to consolidate the expertise in one project that is designed by
experts and fully vetted, this is the role of Barbican. Would you like
to contribute to Barbican? I'm sure your skills would be a tremendous
asset.


--
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