Open Stack

Extremely interesting.

This is something that we are looking at during the Security mid-cycle
(happening this week) see "Secure communications between control plane and
tenant plane” under
https://etherpad.openstack.org/p/security-liberty-midcycle

This is problem for a lot of different projects, we’ve added your
blueprint and hopefully we’ll be able to help with this moving forward.

-Rob



On 01/09/2015 11:11, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:

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