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 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 <lbrags...@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 <j...@johngarbutt.com> > 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.li...@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 <joehu...@huawei.com> wrote: >>> >>>> I think a option 2 is better. >>>> >>>> Best Regards >>>> Chaoyi Huang (joehuang) >>>> ------------------------------ >>>> *From:* Lance Bragstad [lbrags...@gmail.com] >>>> *Sent:* 25 May 2017 3:47 >>>> *To:* OpenStack Development Mailing List (not for usage questions); >>>> openstack-operators@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/3d033df1c0fdc >>>> 6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342 >>>> >>>> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbrags...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>> >>>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators