Open Stack

On Thu, Mar 16, 2017 at 2:53 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
> 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?

This is a good question but I'm not sure it belongs to this threads,
since it's not related to Fernet tokens storage backend.

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

They have one thing in common: etcd (or a key/value store used by
OpenStack projects, for storing stuffs (config, tokens, etc?).

Thanks,

> 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
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Emilien Macchi