On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote: > On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad <[email protected]> > wrote: > > > > > > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckmann@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@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 <[email protected] > > > 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 > > > <[email protected]> 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 <[email protected]> > > > wrote: > > > > > > I think a option 2 is better. > > > > > > Best Regards > > > Chaoyi Huang (joehuang) > > > ________________________________ > > > From: Lance Bragstad [[email protected]] > > > Sent: 25 May 2017 3:47 > > > To: OpenStack Development Mailing List (not for usage questions); > > > [email protected] > > > 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@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 > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope > > > rators > > > > > > _______________________________________________ > > > OpenStack-operators mailing list > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope > > > rators > > > > > > > > > _______________________________________________ > > > OpenStack-operators mailing list > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope > > > rators > > > > > > > > > > > > > > > > > > _______________________________________________ > > > OpenStack-operators mailing list > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope > > > rators > > > > > > > > _______________________________________________ > > OpenStack-operators mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-opera > > tors > > _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
