Open Stack

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 <emilien at redhat.com> wrote:

> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi <emilien at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/582fd453/attachment.html>