On Fri, Jun 9, 2017 at 11:17 AM, Clint Byrum <[email protected]> wrote:
> 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 <[email protected]> > wrote: > > > > > On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <[email protected]> > > > 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]. > Great point, and thanks for leaving it in the spec. I'm glad we're getting this documented since this specific discussion has cropped up a couple times. > > [1] https://www.vaultproject.io/ > [2] https://docs.openstack.org/developer/castellan/ > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
