Open Stack

I’ve requested several Security Project slots on the summit timetable, I’d
be happy to dedicate a fishbowl session to this on the security track.

-Rob

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

>Awesome. Thanks. :)
>
>Are there any plans for the summit yet? I think we should all get
>together and talk about it.
>
>Thanks,
>Kevin
>________________________________________
>From: Clark, Robert Graham [robert.clark at hp.com]
>Sent: Tuesday, September 01, 2015 1:35 PM
>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
>
>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
>
>__________________________________________________________________________
>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