Open Stack

Excerpts from Lance Bragstad's message of 2017-06-08 16:10:00 -0500:
> On Thu, Jun 8, 2017 at 3:21 PM, Emilien Macchi <emilien at redhat.com> wrote:
> 
> > On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <lbragstad at gmail.com>
> > wrote:
> > > After digging into etcd a bit, one place this might be help deployer
> > > experience would be the handling of fernet keys for token encryption in
> > > keystone. Currently, all keys used to encrypt and decrypt tokens are
> > kept on
> > > disk for each keystone node in the deployment. While simple, it requires
> > > operators to perform rotation on a single node and then push, or sync,
> > the
> > > new key set to the rest of the nodes. This must be done in lock step in
> > > order to prevent early token invalidation and inconsistent token
> > responses.
> >
> > This is what we discussed a few months ago :-)
> >
> > http://lists.openstack.org/pipermail/openstack-dev/2017-March/113943.html
> >
> > I'm glad it's coming back ;-)
> >
> 
> Yep! I've proposed a pretty basic spec to backlog [0] in an effort to
> capture the discussion. I've also noted the point Kevin brought up about
> authorization in etcd (thanks, Kevin!)
> 
> If someone feels compelled to take that and run with it, they are more than
> welcome to.
> 
> [0] https://review.openstack.org/#/c/472385/
> 

I commented on the spec. I think this is a misguided idea. etcd3 is a
_coordination_ service. Not a key manager. It lacks the audit logging
and access control one expects to protect and manage key material. I'd
much rather see something like Hashicorp's Vault [1] implemented for
Fernet keys than etcd3. We even have a library for such things called
Castellan[2].

[1] https://www.vaultproject.io/
[2] https://docs.openstack.org/developer/castellan/