Open Stack

Yeah, that's a good point. If we end up with something like etcd does all
config have to be in there, or can we limit it to certain parts of config?

For some reason I was expecting more correlation between these two topics.
I apologize for getting my wires crossed.

On Thu, Mar 16, 2017 at 1:02 PM, Davanum Srinivas <davanum at gmail.com> wrote:

> Lance,
>
> in the other thread, we have not been talking about having any kind of
> security for the fernet keys. Isn't that a requirement since if we
> throw that in etcd it may be vulnerable?
>
> Thanks,
> Dims
>
> On Thu, Mar 16, 2017 at 12:45 PM, Lance Bragstad <lbragstad at gmail.com>
> wrote:
> > 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
> >
> >
> >
> > ____________________________________________________________
> ______________
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> 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/238fc03a/attachment.html>