I think the success of this, or a revived fernet-backend spec, is going to have a hard requirement on the outcome of the configuration opts discussion [0]. When we attempted to introduce an abstraction for fernet keys previously, it led down a rabbit hole of duplicated work across implementations, which was part of the reason for dropping the spec.
[0] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113941.html On Thu, Mar 16, 2017 at 10:12 AM, Emilien Macchi <emil...@redhat.com> wrote: > On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi <emil...@redhat.com> > wrote: > > Folks, > > > > I found useful to share a spec that I started to write this morning: > > https://review.openstack.org/445592 > > > > The goal is to do Keystone Fernet keys rotations in a way that scales > > and is secure, by using the standard tools and not re-inventing the > > wheel. > > In other words: if you're working on Keystone or TripleO or any other > > deployment tool: please read the spec and give any feedback. > > > > We would like to find a solution that would work for all OpenStack > > deployment tools (Kolla, OSA, Fuel, TripleO, Helm, etc) but I sent the > > specs to tripleo project > > to get some feedback. > > > > If you already has THE solution that you think is the best one, then > > we would be very happy to learn from it in a comment directly in the > > spec. > > > > After 2 days of review from Keystone, TripleO, OSA (and probably some > groups I missed), it's pretty clear the problem is already being fixed > in different places in different ways and that's bad. > IMHO we should engage some work to fix it in Keystone and investigate > again a storage backend for Keystone tokens. > > The Keystone specs that started this investigation was removed for Pike: > https://review.openstack.org/#/c/439194/ > > I see 2 options here: > > - we keep duplicating efforts and let deployers implement their own > solutions. > > - we work with Keystone team to re-enable the spec and move forward to > solve the problem in Keystone itself, therefore for all deployments > tools in OpenStack (my favorite option). > > > I would like to hear from Keystone folks what are the main blockers > for option #2 and if this is only a human resource issue or if there > is some technical points we need to solve (in that case, it could be > done in the specs). > > > Thanks, > -- > Emilien Macchi > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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