Open Stack

-----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 would be a tremendous asset.
> 
> 

Rob does help out on Barbican occasionally, and I agree his skills are
a tremendous asset. :)
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV5fC3AAoJEB7Z2EQgmLX7/+0P/i/YwO+LlONywiJkNZCHe7+D
Bx7W4BXu9L+fiStF8DFtFXeU/LZ0de8SOk8rCRQ4f2ZS3nDscE/B6NumooVo7rPI
tz/0Er9Tu2mFmObPaCzbcX5la1+6U3JVP4qzFoQ9Yxu+Ai5Kbav36c+P97v3fy6N
uwMm8UiZDGEgH9Z168C6X0qSJ2KOk2/34osxxllfFizYcKTu4A1PQDZbavB5btQ5
k9zOtNoEyiQcwOcyAa6Jr2/QYsiSthMZ33Q7BPkCa6h2vNUGt2wESSgroB+ThWJL
P8NkLZAhHM4Q+mULucmKcDlqNYb/nb/XOlsW1VTgVF0W1wYa7TqnFLqCptmjLCE/
d2P46OqV0eKN7uR6bK8xRrvbX66qTMm5pQN4mAmKPf9Oomj/9M4bsOjv4GhSf04+
o83Y/V4avcDKiO8zS19G/T7nay+YbBGSndjGATxr5EtmePIudHj98ygpGoo4vAOM
aLFCVYDIjTPvI9kWZUFD1wGu6hkUfeSpLFHjQfd1llt9qOgBhIb7R2cNE8mJMWWM
aZzbklGlp+SA6AzYF6x5WnMmr3C1MJngaRq9AL7S+0ti504eE5bibwtJjh91c8jo
v+pGC+A0+gw/x1fHijB+aUij15t8rH8FWnIsLXUBzrukt2xLJdpATrvef+6JI+QL
/Vqul3W0RzPRaoRp1bWc
=jtb/
-----END PGP SIGNATURE-----