Nice. Thank you. Kevin ________________________________________ From: Clark, Robert Graham [robert.cl...@hp.com] Sent: Tuesday, September 01, 2015 3:16 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
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....@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.cl...@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....@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 [jden...@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-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 > >__________________________________________________________________________ >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 __________________________________________________________________________ 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
