>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