Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Emilien Macchi]

On Thu, Mar 16, 2017 at 2:53 PM, Lance Bragstad  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  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 
>> 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 
>> > wrote:
>> >>
>> >> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi 
>> >> 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
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> 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
> 

Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Lance Bragstad]

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  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 
> 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 
> wrote:
> >>
> >> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi 
> >> 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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

Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Davanum Srinivas]

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  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  wrote:
>>
>> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi 
>> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Lance Bragstad]

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  wrote:

> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi 
> 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

Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Emilien Macchi]

On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi  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-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

[Emilien Macchi]

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.

Thanks for your time,
-- 
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