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
