On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann <[email protected]> wrote:
> First of all @Lance, thanks for taking the time to write and summarize > this for us. It's much appreciated. > Absolutely! it helps me think about it, too. > > While I'm not aware of all the nuances, based on my own testing, I feel > that we are really close with option 1. > > That being said, as you already stated, option 2 is clearly more inline > with the idea of having a "global" Cloud Admin role. So long term, #2 is > more desirable. > > Given the two sentences above, I certainly would prefer option 3 so that > we can have a usable solution quickly. I certainly will continue to test > and provide feedback for the option 1 part. > > It sounds like eventually migrating everything from the is_admin_project to true global roles is a migration you're willing to make. This might be a loaded question and it will vary across deployments, but how long would you expect that migration to take for you're specific deployment(s)? -m > > > > > On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote: > > > > On 25/05/17 07:47, Lance Bragstad wrote: > <snip> > > *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 > > <snip> > > > On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <[email protected]> > 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! > > > Please option 2. The concept of being an "admin" while you are only scoped > to a project is stupid when that admin role gives you super user power yet > you only have it when scoped to just that project. That concept never > really made sense. Global scope makes so much more sense when that is the > power the role gives. > > At same time, it kind of would be nice to make scope actually matter. As > admin you have a role on Project X, yet you can now (while scoped to this > project) pretty much do anything anywhere! I think global roles is a great > step in the right direction, but beyond and after that we need to seriously > start looking at making scope itself matter, so that giving someone 'admin' > or some such on a project actually only gives them something akin to > project_admin or some sort of admin-lite powers scoped to that project and > sub-projects. That though falls into the policy work being done, but should > be noted, as it is related. > > Still, at least global scope for roles make the superuser case make some > actual sense, because (and I can't speak for other deployers), we have one > project pretty much dedicated as an "admin_project" and it's just odd to > actually need to give our service users roles in a project when that > project is empty and a pointless construct for their purpose. > > Also thanks for pushing this! I've been watching your global roles spec > review in hopes we'd go down that path. :) > > -Adrian > > _______________________________________________ > OpenStack-operators mailing > [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
