Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec
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 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __
Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec
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
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
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
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
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