Open Stack

On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote:
> On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad <lbragstad at gmail.com>
> wrote:
> > 
> > 
> > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckmann at ubisof
> > t.com>
> > wrote:
> > > 
> > > Hi,
> > > 
> > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote:
> > > 
> > > Also, with all the people involved with this thread, I'm curious
> > > what the
> > > best way is to get consensus. If I've tallied the responses
> > > properly, we
> > > have 5 in favor of option #2 and 1 in favor of option #3. This
> > > week is spec
> > > freeze for keystone, so I see a slim chance of this getting
> > > committed to
> > > Pike [0]. If we do have spare cycles across the team we could
> > > start working
> > > on an early version and get eyes on it. If we straighten out
> > > everyone
> > > concerns early we could land option #2 early in Queens.
> > > 
> > > 
> > > I was the only one in favour of option 3 only because I've spent
> > > a bunch
> > > of time playing with option #1 in the past. As I mentioned
> > > previously in the
> > > thread, if #2 is more in line with where the project is going,
> > > then I'm all
> > > for it. At this point, the admin scope issue has been around long
> > > enough
> > > that Queens doesn't seem that far off.
> > 
> > 
> > From an administrative point-of-view, would you consider option #1
> > or option
> > #2 to better long term?

#2

> > 
> 
> Count me as another +1 for option 2. It's the right way to go long
> term, and we've lived with how it is now long enough that I'm OK
> waiting a release or even 2 more for it with things as is. I think
> option 3 would just muddy the waters.
> 
> -Erik
> 
> > > 
> > > 
> > > -m
> > > 
> > > 
> > > I guess it comes down to how fast folks want it.
> > > 
> > > [0] https://review.openstack.org/#/c/464763/
> > > 
> > > On Tue, Jun 6, 2017 at 10:01 AM, Lance Bragstad <lbragstad at gmail.
> > > com>
> > > wrote:
> > > 
> > > I replied to John, but directly. I'm sending the responses I sent
> > > to him
> > > but with the intended audience on the thread. Sorry for not
> > > catching that
> > > earlier.
> > > 
> > > 
> > > On Fri, May 26, 2017 at 2:44 AM, John Garbutt <john at johngarbutt.c
> > > om>
> > > wrote:
> > > 
> > > +1 on not forcing Operators to transition to something new twice,
> > > even if
> > > we did go for option 3.
> > > 
> > > 
> > > The more I think about this, the more it worries me from a
> > > developer
> > > perspective. If we ended up going with option 3, then we'd be
> > > supporting
> > > both methods of elevating privileges. That means two paths for
> > > doing the
> > > same thing in keystone. It also means oslo.context,
> > > keystonemiddleware, or
> > > any other library consuming tokens that needs to understand
> > > elevated
> > > privileges needs to understand both approaches.
> > > 
> > > 
> > > 
> > > Do we have an agreed non-distruptive upgrade path mapped out yet?
> > > (For any
> > > of the options) We spoke about fallback rules you pass but with a
> > > warning to
> > > give us a smoother transition. I think that's my main objection
> > > with the
> > > existing patches, having to tell all admins to get their token
> > > for a
> > > different project, and give them roles in that project, all
> > > before being
> > > able to upgrade.
> > > 
> > > 
> > > Thanks for bringing up the upgrade case! You've kinda described
> > > an upgrade
> > > for option 1. This is what I was thinking for option 2:
> > > 
> > > - deployment upgrades to a release that supports global role
> > > assignments
> > > - operator creates a set of global roles (i.e. global_admin)
> > > - operator grants global roles to various people that need it
> > > (i.e. all
> > > admins)
> > > - operator informs admins to create globally scoped tokens
> > > - operator rolls out necessary policy changes
> > > 
> > > If I'm thinking about this properly, nothing would change at the
> > > project-scope level for existing users (who don't need a global
> > > role
> > > assignment). I'm hoping someone can help firm ^ that up or
> > > improve it if
> > > needed.
> > > 
> > > 
> > > 
> > > Thanks,
> > > johnthetubaguy
> > > 
> > > On Fri, 26 May 2017 at 08:09, Belmiro Moreira
> > > <moreira.belmiro.email.lists at gmail.com> wrote:
> > > 
> > > Hi,
> > > thanks for bringing this into discussion in the Operators list.
> > > 
> > > Option 1 and 2 and not complementary but complety different.
> > > So, considering "Option 2" and the goal to target it for Queens I
> > > would
> > > prefer not going into a migration path in
> > > Pike and then again in Queens.
> > > 
> > > Belmiro
> > > 
> > > On Fri, May 26, 2017 at 2:52 AM, joehuang <joehuang at huawei.com>
> > > wrote:
> > > 
> > > I think a option 2 is better.
> > > 
> > > Best Regards
> > > Chaoyi Huang (joehuang)
> > > ________________________________
> > > From: Lance Bragstad [lbragstad at gmail.com]
> > > Sent: 25 May 2017 3:47
> > > To: OpenStack Development Mailing List (not for usage questions);
> > > openstack-operators at lists.openstack.org
> > > Subject: Re: [openstack-dev]
> > > [keystone][nova][cinder][glance][neutron][horizon][policy]
> > > defining
> > > admin-ness
> > > 
> > > I'd like to fill in a little more context here. I see three
> > > options with
> > > the current two proposals.
> > > 
> > > Option 1
> > > 
> > > Use a special admin project to denote elevated privileges. For
> > > those
> > > unfamiliar with the approach, it would rely on every deployment
> > > having an
> > > "admin" project defined in configuration [0].
> > > 
> > > How it works:
> > > 
> > > Role assignments on this project represent global scope which is
> > > denoted
> > > by a boolean attribute in the token response. A user with an
> > > 'admin' role
> > > assignment on this project is equivalent to the global or cloud
> > > administrator. Ideally, if a user has a 'reader' role assignment
> > > on the
> > > admin project, they could have access to list everything within
> > > the
> > > deployment, pending all the proper changes are made across the
> > > various
> > > services. The workflow requires a special project for any sort of
> > > elevated
> > > privilege.
> > > 
> > > Pros:
> > > - Almost all the work is done to make keystone understand the
> > > admin
> > > project, there are already several patches in review to other
> > > projects to
> > > consume this
> > > - Operators can create roles and assign them to the admin_project
> > > as
> > > needed after the upgrade to give proper global scope to their
> > > users
> > > 
> > > Cons:
> > > - All global assignments are linked back to a single project
> > > - Describing the flow is confusing because in order to give
> > > someone global
> > > access you have to give them a role assignment on a very specific
> > > project,
> > > which seems like an anti-pattern
> > > - We currently don't allow some things to exist in the global
> > > sense (i.e.
> > > I can't launch instances without tenancy), the admin project
> > > could own
> > > resources
> > > - What happens if the admin project disappears?
> > > - Tooling or scripts will be written around the admin project,
> > > instead of
> > > treating all projects equally
> > > 
> > > Option 2
> > > 
> > > Implement global role assignments in keystone.
> > > 
> > > How it works:
> > > 
> > > Role assignments in keystone can be scoped to global context.
> > > Users can
> > > then ask for a globally scoped token
> > > 
> > > Pros:
> > > - This approach represents a more accurate long term vision for
> > > role
> > > assignments (at least how we understand it today)
> > > - Operators can create global roles and assign them as needed
> > > after the
> > > upgrade to give proper global scope to their users
> > > - It's easier to explain global scope using global role
> > > assignments
> > > instead of a special project
> > > - token.is_global = True and token.role = 'reader' is easier to
> > > understand
> > > than token.is_admin_project = True and token.role = 'reader'
> > > - A global token can't be associated to a project, making it
> > > harder for
> > > operations that require a project to consume a global token (i.e.
> > > I
> > > shouldn't be able to launch an instance with a globally scoped
> > > token)
> > > 
> > > Cons:
> > > - We need to start from scratch implementing global scope in
> > > keystone,
> > > steps for this are detailed in the spec
> > > 
> > > Option 3
> > > 
> > > We do option one and then follow it up with option two.
> > > 
> > > How it works:
> > > 
> > > We implement option one and continue solving the admin-ness
> > > issues in Pike
> > > by helping projects consume and enforce it. We then target the
> > > implementation of global roles for Queens.
> > > 
> > > Pros:
> > > - If we make the interface in oslo.context for global roles
> > > consistent,
> > > then consuming projects shouldn't know the difference between
> > > using the
> > > admin_project or a global role assignment
> > > 
> > > Cons:
> > > - It's more work and we're already strapped for resources
> > > - We've told operators that the admin_project is a thing but
> > > after Queens
> > > they will be able to do real global role assignments, so they
> > > should now
> > > migrate *again*
> > > - We have to support two paths for solving the same problem in
> > > keystone,
> > > more maintenance and more testing to ensure they both behave
> > > exactly the
> > > same way
> > >   - This can get more complicated for projects dedicated to
> > > testing policy
> > > and RBAC, like Patrole
> > > 
> > > 
> > > Looking for feedback here as to which one is preferred given
> > > timing and
> > > payoff, specifically from operators who would be doing the
> > > migrations to
> > > implement and maintain proper scope in their deployments.
> > > 
> > > Thanks for reading!
> > > 
> > > 
> > > [0]
> > > https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02
> > > a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342
> > > 
> > > On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbragstad at gmail
> > > .com>
> > > wrote:
> > > 
> > > Hey all,
> > > 
> > > To date we have two proposed solutions for tackling the admin-
> > > ness issue
> > > we have across the services. One builds on the existing scope
> > > concepts by
> > > scoping to an admin project [0]. The other introduces global role
> > > assignments [1] as a way to denote elevated privileges.
> > > 
> > > I'd like to get some feedback from operators, as well as
> > > developers from
> > > other projects, on each approach. Since work is required in
> > > keystone, it
> > > would be good to get consensus before spec freeze (June 9th). If
> > > you have
> > > specific questions on either approach, feel free to ping me or
> > > drop by the
> > > weekly policy meeting [2].
> > > 
> > > Thanks!
> > > 
> > > [0] http://adam.younglogic.com/2017/05/fixing-bug-96869/
> > > [1] https://review.openstack.org/#/c/464763/
> > > [2] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > > 
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > > 
> > > 
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > 
> > 
> > 
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-opera
> > tors
> >