<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 25/05/17 07:47, Lance Bragstad
wrote:<br>
<snip></div>
<blockquote type="cite"
cite="mid:CAE6oFcGVJLkLu5JLpiZjJWErP-051V=DFD7phFNM_whaYEiKEg@mail.gmail.com">
<div dir="ltr"><b>Option 2</b>
<div><br>
</div>
<div>Implement global role assignments in keystone.</div>
<div><i><br>
</i></div>
<div><i>How it works:</i></div>
<div><i><br>
</i></div>
<div>Role assignments in keystone can be scoped to global
context. Users can then ask for a globally scoped token </div>
<div><br>
</div>
<div>Pros:</div>
<div>- This approach represents a more accurate long term vision
for role assignments (at least how we understand it today)</div>
<div>- Operators can create global roles and assign them as
needed after the upgrade to give proper global scope to their
users</div>
<div>- It's easier to explain global scope using global role
assignments instead of a special project</div>
<div>- token.is_global = True and token.role = 'reader' is
easier to understand than token.is_admin_project = True and
token.role = 'reader'</div>
<div>- 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)</div>
<div><br>
</div>
<div>Cons:</div>
<div>- We need to start from scratch implementing global scope
in keystone, steps for this are detailed in the spec</div>
<div><br>
</div>
</div>
</blockquote>
<snip><br>
<blockquote type="cite"
cite="mid:CAE6oFcGVJLkLu5JLpiZjJWErP-051V=DFD7phFNM_whaYEiKEg@mail.gmail.com">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, May 24, 2017 at 10:35 AM, Lance
Bragstad <span dir="ltr"><<a
href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hey all,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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].<br>
</div>
<div><br>
</div>
<div>Thanks!<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Also thanks for pushing this! I've been watching your global roles
spec review in hopes we'd go down that path. :)<br>
<br>
-Adrian<br>
</body>
</html>