Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170525/cfa990ca/attachment.html>