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 <emil...@redhat.com> wrote: > > > On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <lbrags...@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/ __________________________________________________________________________ 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