Open Stack

On Thu, Jun 8, 2017 at 3:21 PM, Emilien Macchi <emilien at redhat.com> wrote:

> On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <lbragstad at gmail.com>
> wrote:
> > After digging into etcd a bit, one place this might be help deployer
> > experience would be the handling of fernet keys for token encryption in
> > keystone. Currently, all keys used to encrypt and decrypt tokens are
> kept on
> > disk for each keystone node in the deployment. While simple, it requires
> > operators to perform rotation on a single node and then push, or sync,
> the
> > new key set to the rest of the nodes. This must be done in lock step in
> > order to prevent early token invalidation and inconsistent token
> responses.
>
> This is what we discussed a few months ago :-)
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113943.html
>
> I'm glad it's coming back ;-)
>

Yep! I've proposed a pretty basic spec to backlog [0] in an effort to
capture the discussion. I've also noted the point Kevin brought up about
authorization in etcd (thanks, Kevin!)

If someone feels compelled to take that and run with it, they are more than
welcome to.

[0] https://review.openstack.org/#/c/472385/


> > An alternative would be to keep the keys in etcd and make the fernet bits
> > pluggable so that it's possible to read keys from disk or etcd (pending
> > configuration). The advantage would be that operators could initiate key
> > rotations from any keystone node in the deployment (or using etcd
> directly)
> > and not have to worry about distributing the new key set. Since etcd
> > associates metadata to the key-value pairs, we might be able to simplify
> the
> > rotation strategy as well.
> >
> > On Thu, Jun 8, 2017 at 11:37 AM, Mike Bayer <mbayer at redhat.com> wrote:
> >>
> >>
> >>
> >> On 06/08/2017 12:47 AM, Joshua Harlow wrote:
> >>>
> >>> So just out of curiosity, but do people really even know what etcd is
> >>> good for? I am thinking that there should be some guidance from folks
> in the
> >>> community as to where etcd should be used and where it shouldn't
> (otherwise
> >>> we just all end up in a mess).
> >>
> >>
> >> So far I've seen a proposal of etcd3 as a replacement for memcached in
> >> keystone, and a new dogpile connector was added to oslo.cache to handle
> >> referring to etcd3 as a cache backend.  This is a really simplistic /
> >> minimal kind of use case for a key-store.
> >>
> >> But, keeping in mind I don't know anything about etcd3 other than "it's
> >> another key-store", it's the only database used by Kubernetes as a
> whole,
> >> which suggests it's doing a better job than Redis in terms of "durable".
> >> So I wouldn't be surprised if new / existing openstack applications
> express
> >> some gravitational pull towards using it as their own datastore as well.
> >> I'll be trying to hang onto the etcd3 track as much as possible so that
> >> if/when that happens I still have a job :).
> >>
> >>
> >>
> >>
> >>>
> >>> Perhaps a good idea to actually give examples of how it should be used,
> >>> how it shouldn't be used, what it offers, what it doesn't... Or at
> least
> >>> provide links for people to read up on this.
> >>>
> >>> Thoughts?
> >>>
> >>> Davanum Srinivas wrote:
> >>>>
> >>>> One clarification: Since https://pypi.python.org/pypi/etcd3gw just
> >>>> uses the HTTP API (/v3alpha) it will work under both eventlet and
> >>>> non-eventlet environments.
> >>>>
> >>>> Thanks,
> >>>> Dims
> >>>>
> >>>>
> >>>> On Wed, Jun 7, 2017 at 6:47 AM, Davanum Srinivas<davanum at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Team,
> >>>>>
> >>>>> Here's the update to the base services resolution from the TC:
> >>>>> https://governance.openstack.org/tc/reference/base-services.html
> >>>>>
> >>>>> First request is to Distros, Packagers, Deployers, anyone who
> >>>>> installs/configures OpenStack:
> >>>>> Please make sure you have latest etcd 3.x available in your
> >>>>> environment for Services to use, Fedora already does, we need help in
> >>>>> making sure all distros and architectures are covered.
> >>>>>
> >>>>> Any project who want to use etcd v3 API via grpc, please use:
> >>>>> https://pypi.python.org/pypi/etcd3 (works only for non-eventlet
> >>>>> services)
> >>>>>
> >>>>> Those that depend on eventlet, please use the etcd3 v3alpha HTTP API
> >>>>> using:
> >>>>> https://pypi.python.org/pypi/etcd3gw
> >>>>>
> >>>>> If you use tooz, there are 2 driver choices for you:
> >>>>> https://github.com/openstack/tooz/blob/master/setup.cfg#L29
> >>>>> https://github.com/openstack/tooz/blob/master/setup.cfg#L30
> >>>>>
> >>>>> If you use oslo.cache, there is a driver for you:
> >>>>> https://github.com/openstack/oslo.cache/blob/master/setup.cfg#L33
> >>>>>
> >>>>> Devstack installs etcd3 by default and points cinder to it:
> >>>>> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/etcd3
> >>>>>
> >>>>> http://git.openstack.org/cgit/openstack-dev/devstack/tree/
> lib/cinder#n356
> >>>>>
> >>>>> Review in progress for keystone to use etcd3 for caching:
> >>>>> https://review.openstack.org/#/c/469621/
> >>>>>
> >>>>> Doug is working on proposal(s) for oslo.config to store some
> >>>>> configuration in etcd3:
> >>>>> https://review.openstack.org/#/c/454897/
> >>>>>
> >>>>> So, feel free to turn on / test with etcd3 and report issues.
> >>>>>
> >>>>> Thanks,
> >>>>> Dims
> >>>>>
> >>>>> --
> >>>>> 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
> >
> >
> >
> > ____________________________________________________________
> ______________
> > 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
>
> __________________________________________________________________________
> 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/20170608/8566288e/attachment-0001.html>