On Thu, Mar 16, 2017 at 2:53 PM, Lance Bragstad <lbrags...@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 <dava...@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 <lbrags...@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 <emil...@redhat.com> >> > wrote: >> >> >> >> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi <emil...@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-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 __________________________________________________________________________ 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