Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Fox, Kevin M]

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Fox, Kevin M]

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

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"  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/opensta

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

On 01/09/2015 11:38, "Douglas Mendizábal"
 wrote:

This turned into exactly what I was trying to avoid, I probably shouldn’t
have mentioned Anchor, but as I started us down this road (where really I
was just expressing some concerns over certificate lifecycle) please see
my comments below :)

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Added a few comments inline.
>
>- - Douglas Mendizábal
>
>On 9/1/15 12:03 PM, John Dennis wrote:
>> 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.
>>> 
>
>Barbican provides a lot of options for provisioning certificates. We
>do support provisioning certs by only passing a CSR so that clients
>can keep ownership of their keys, if that's what the client prefers.
>
>Of course, when you're provisioning keys for every node in a cluster
>for many clusters then key management becomes an issue, and if these
>are not throwaway keys, then storing them in Barbican makes sense.
>
>We can also provision the keys, and create CSRs on the Barbican side,
>so we make it very easy for clients who don't want to do any of this
>locally.

I wasn’t bashing Barbican, just the way that it looks like it’s being used
here, as I said, there’s good reasons why Barbican works the way it does,
but not all available options are appropriate for all types of deployments.



>
>>> 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).
>>> 
>
>Kevin Fox is working on a Nova spec to provide identity to VMs. I'm
>really hoping this spec gains some traction because it's a problem
>that not only Barbican, but all other user-facing projects can benefit
>from.
>
>See: https://blueprints.launchpad.net/nova/+spec/instance-users
>
>>> 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.
>>> 
>
>Someone from the Magnum team can correct me if I'm wrong, but I do
>believe they considered Anchor for certificate provisioning.
>
>As I understand the Magnum use case, they will be provisioning many
>clusters across different tenants. While Anchor would work well for a
>single cluster, they need the ability to provision new CA roots for
>each and every cluster, and then provision certs off that root for
>every node in the cluster. This way node certs are only valid in the
>context of the cluster.
>
>A new feature for Barbican Liberty will be the ability to add new CA
>roots scoped to a tenant via API, which will address the Magnum
>requirements of separating the certificate roots per cluster.

Interestingly, we recently added support for this, you can have multiple
CA roots within Anchor. When we announced it a few summits back we
focussed on how you can use Anchor in silo’d deployments where you would
spin up an instance for each cluster but recently we added the ability to
run Anchor with multiple CA roots, each can have it’s own auth and it’s
own validation chain.


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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Added a few comments inline.

- - Douglas Mendizábal

On 9/1/15 12:03 PM, John Dennis wrote:
> 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.
>> 

Barbican provides a lot of options for provisioning certificates. We
do support provisioning certs by only passing a CSR so that clients
can keep ownership of their keys, if that's what the client prefers.

Of course, when you're provisioning keys for every node in a cluster
for many clusters then key management becomes an issue, and if these
are not throwaway keys, then storing them in Barbican makes sense.

We can also provision the keys, and create CSRs on the Barbican side,
so we make it very easy for clients who don't want to do any of this
locally.

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

Kevin Fox is working on a Nova spec to provide identity to VMs. I'm
really hoping this spec gains some traction because it's a problem
that not only Barbican, but all other user-facing projects can benefit
from.

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

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

Someone from the Magnum team can correct me if I'm wrong, but I do
believe they considered Anchor for certificate provisioning.

As I understand the Magnum use case, they will be provisioning many
clusters across different tenants. While Anchor would work well for a
single cluster, they need the ability to provision new CA roots for
each and every cluster, and then provision certs off that root for
every node in the cluster. This way node certs are only valid in the
context of the cluster.

A new feature for Barbican Liberty will be the ability to add new CA
roots scoped to a tenant via API, which will address the Magnum
requirements of separating the certificate roots per cluster.

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

We've talked about this before with the Security team, and I agree
that adding a CA plugin to Barbican to support Anchor would be awesome.

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Adrian Otto]

John and Robert,

On Sep 1, 2015, at 10:03 AM, John Dennis 
mailto:jden...@redhat.com>> wrote:

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

Exactly. Using Keystone trust tokens was one option we discussed, but placing 
those on the bay nodes is problematic. They currently offer us the rough 
equivalent of a regular keystone token because not all OpenStack services check 
for the scope of the token used to auth against the service, meaning that a 
trust token is effectively a bearer token for interacting with most of 
OpenStack. We woodenly to land patches in *every* OpenStack project in order to 
work around this gap. This is simply not practical in the time we have before 
the Liberty release, and is much more work than our contributors signed up for. 
Both our Magnum team and our Barbican team met about this together at our 
recent Midcycle meetup. We did talk about how to put additional trust support 
capabilities into Barbican to allow delegation and restricted use of Barbican 
by individual service accounts.

The bottom line is that we need a functional TLS implementation in Magnum for 
Kubernetes and Docker Swarm to use now, and we can’t in good conscious claim 
that Magnum is suitable for production workloads until we address this. If we 
have to take some shortcuts to get this done, then that’s fine, as long as we 
commit to revisiting our design compromises and correcting them.

There is another ML thread that references a new Nova spec for “Instance Users” 
which is still in concept stage:

https://review.openstack.org/186617

We need something now, even if it’s not perfect. The thing we must solve for 
first is that we don’t have Kubernetes and Docker API’s that are open on public 
networks that are unprotected (no authentication), and allow anyone to just 
start stuff up on your container clusters. We are going to crawl before we 
walk/run here. We plan to use a TLS certificate to work as an authentication 
mechanism so that if you don’t have the correct certificate, you can’t 
communicate with the TLS enabled API port.

This is what we are doing as a first step:

https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:bp/magnum-as-a-ca,n,z

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.

That would be cool. I’m not sure that the use case for Anchor exactly fits into 
Barbican’s concept of a CA, but if there were a clean integration point there, 
I’d love to use it.

What I don't want to see is spinning our w

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Fox, Kevin M]

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[John Dennis]

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

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



__
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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[John Dennis]

On 09/01/2015 02:49 AM, Tim Bell wrote:

Will it also be possible to use a different CA ? In some
environments, there is already a corporate certificate authority
server. This would ensure compliance with site security standards.


A configurable CA was one of the original design goals when the Barbican 
work began. I have not tracked the work so I don't know if that is still 
the case, Ade Lee would know for sure.


--
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-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Vikas Choudhary]

Is it like keystone authenticating between magnum-client and magnum conductor,

and barbican certs will be used b/w conductor and k8s/swarm?



Thanks

Vikas Choudhary

_
Simply put, Keystone is designed to generate  tokens that are to be
used for authentication and RBAC. Systems like Kunernetes do not
support Keystone auth, but do support TLS. Using TLS provides a
solution that is compatible with using these systems outside of an
OpenStack cloud.

Barbican is designed for secure storage of arbitrary secrets, and
currently also has a CA function. 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.

We are taking an iterative approach to TLS integration, so we can
gradually take advantage of both keystone and Barbican features as
they allow us to iterate toward a more secure integration.

Adrian

>* On Aug 31, 2015, at 9:05 PM, Vikas Choudhary  
>>> wrote:
*>>* Hi,
*>>* Can anybody please point me out some etherpad discussion
page/spec  that can help me understand why we are going to introduce
barbican  for magnum when we already had keystone for security
management?
*>* -Vikas Choudhary
*>>
__
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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Tim Bell]

> -Original Message-
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: 01 September 2015 07:03
> 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
> 
> Simply put, Keystone is designed to generate  tokens that are to be used for
> authentication and RBAC. Systems like Kunernetes do not support Keystone
> auth, but do support TLS. Using TLS provides a solution that is compatible
> with using these systems outside of an OpenStack cloud.
> 
> Barbican is designed for secure storage of arbitrary secrets, and currently
> also has a CA function. 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.
> 

Will it also be possible to use a different CA ? In some environments, there is 
already a corporate certificate authority server. This would ensure compliance 
with site security standards.

Tim

> We are taking an iterative approach to TLS integration, so we can gradually
> take advantage of both keystone and Barbican features as they allow us to
> iterate toward a more secure integration.
> 
> Adrian
> 
> > On Aug 31, 2015, at 9:05 PM, Vikas Choudhary
>  wrote:
> >
> > Hi,
> >
> > Can anybody please point me out some etherpad discussion page/spec
> that can help me understand why we are going to introduce barbican  for
> magnum when we already had keystone for security management?
> >
> >
> >
> >
> > -Vikas Choudhary
> >
> >
> >
> 
> __
> >  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-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Vikas Choudhary]

Thanks Adrian for description.

If i could understand correctly,magnum clients will be use barbican
for authentication as coes dont support keystone for operations like
pod-creation

etc and for rest of the project clients like nova/glance
pythonclients, keystone will continue to serve.

Please correct me.



-Vikas


_
*Simply put, Keystone is designed to generate  tokens that are to be
used for authentication and RBAC. Systems like Kunernetes do not
support Keystone auth, but do support TLS. Using TLS provides a
solution that is compatible with using these systems outside of an
OpenStack cloud.

Barbican is designed for secure storage of arbitrary secrets, and
currently also has a CA function. 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.

We are taking an iterative approach to TLS integration, so we can
gradually take advantage of both keystone and Barbican features as
they allow us to iterate toward a more secure integration.

Adrian

> On Aug 31, 2015, at 9:05 PM, Vikas Choudhary  > wrote:
>
> Hi,
>
> Can anybody please point me out some etherpad discussion page/spec  that can 
> help me understand why we are going to introduce barbican  for magnum when we 
> already had keystone for security management?
>
>
>
>
> -Vikas Choudhary
>
>
> __*
__
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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Adrian Otto]

Simply put, Keystone is designed to generate  tokens that are to be used for 
authentication and RBAC. Systems like Kunernetes do not support Keystone auth, 
but do support TLS. Using TLS provides a solution that is compatible with using 
these systems outside of an OpenStack cloud.

Barbican is designed for secure storage of arbitrary secrets, and currently 
also has a CA function. 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.

We are taking an iterative approach to TLS integration, so we can gradually 
take advantage of both keystone and Barbican features as they allow us to 
iterate toward a more secure integration.

Adrian

> On Aug 31, 2015, at 9:05 PM, Vikas Choudhary  
> wrote:
> 
> Hi,
> 
> Can anybody please point me out some etherpad discussion page/spec  that can 
> help me understand why we are going to introduce barbican  for magnum when we 
> already had keystone for security management?
> 
> 
> 
> 
> -Vikas Choudhary
> 
> 
> __
> 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-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Vikas Choudhary]

Hi,

Can anybody please point me out some etherpad discussion page/spec  that
can help me understand why we are going to introduce barbican  for magnum
when we already had keystone for security management?




-Vikas Choudhary
__
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