<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
John and Robert,
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 1, 2015, at 10:03 AM, John Dennis <<a href="mailto:jdennis@redhat.com" class="">jdennis@redhat.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">The reason that is compelling is that you can have Barbican generate,<br class="">
sign, and store a keypair without transmitting the private key over the<br class="">
network to the client that originates the signing request. It can be<br class="">
directly stored, and made available only to the clients that need access<br class="">
to it.<br class="">
</blockquote>
<br class="">
This is absolutely _not_ how PKI for TLS is supposed to work, yes Barbican<br class="">
can create keypairs etc because sometimes that¹s useful but in the<br class="">
public-private PKI model that TLS expects this is completely wrong. Magnum<br class="">
nodes should be creating their own private key and CSR and submitting them<br class="">
to some CA for signing.<br class="">
<br class="">
Now this gets messy because you probably don¹t want to push keystone<br class="">
credentials onto each node (that they would use to communicate with<br class="">
Barbican).<br class="">
</blockquote>
</div>
</blockquote>
<div><br class="">
</div>
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. </div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>There is another ML thread that references a new Nova spec for “Instance Users” which is still in concept stage:</div>
<div><br class="">
</div>
<div><a href="https://review.openstack.org/186617" class="">https://review.openstack.org/186617</a></div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>This is what we are doing as a first step:</div>
<div><br class="">
</div>
<div><a href="https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:bp/magnum-as-a-ca,n,z" class="">https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:bp/magnum-as-a-ca,n,z</a></div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class="">I¹m a bit conflicted writing this next bit because I¹m not particularly<br class="">
familiar with the Kubernetes/Magnum architectures and also because I¹m one<br class="">
of the core developers for Anchor but here goesŠ.<br class="">
<br class="">
Have you considered using Anchor for this? It¹s a pretty lightweight<br class="">
ephemeral CA that is built to work well in small PKI communities (like a<br class="">
Kubernetes cluster) you can configure multiple methods for authentication<br class="">
and build pretty simple validation rules for deciding if a host should be<br class="">
given a certificate. Anchor is built to provide short-lifetime<br class="">
certificates where each node re-requests a certificate typically every<br class="">
12-24 hours, this has some really nice properties like ³passive<br class="">
revocation² (Think revocation that actually works) and strong ways to<br class="">
enforce issuing logic on a per host basis.<br class="">
<br class="">
Anchor or not, I¹d like to talk to you more about how you¹re attempting to<br class="">
secure Magnum - I think it¹s an extremely interesting project that I¹d<br class="">
like to help out with.<br class="">
<br class="">
-Rob<br class="">
(Security Project PTL / Anchor flunkie)<br class="">
</blockquote>
<br class="">
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.<br class="">
<br class="">
The Barbican blueprint states:<br class="">
<br class="">
Barbican supports full lifecycle management including provisioning, expiration, reporting, etc. A plugin system allows for multiple certificate authority support (including public and private CAs).<br class="">
<br class="">
Perhaps Anchor would be a great candidate for a Barbican plugin.<br class="">
</div>
</blockquote>
<div><br class="">
</div>
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.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">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.</div>
</blockquote>
<br class="">
</div>
<div>To be clear, Magnum has no interest in overlapping with Barbican. To the extent that we can iterate, and remove the cryptography code from Magnum, and leverage it in Barbican, we will do that over time, because we don’t want a duplicated support burden
for that codebase. We would applaud collaboration between Anchor and Barbican, as we found navigating the capabilities of each of these choices to be rather confusing.</div>
<div><br class="">
</div>
<div>Thanks,</div>
<div><br class="">
</div>
<div>Adrian</div>
<br class="">
</div>
</body>
</html>