Open Stack

First of all @Lance, thanks for taking the time to write and summarize this for us. It's much appreciated.

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.

-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 <lbragstad at gmail.com<mailto: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!


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 list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170525/e65154bc/attachment.html>