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-operat...@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/ > 3d033df1c0fdc6cc9d2b02a702efca286371f2bd/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-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
__________________________________________________________________________ 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
