<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/22/2015 05:16 AM, William M
Edmonds wrote:<br>
</div>
<blockquote
cite="mid:201510220916.t9M9GfXu021473@d03av04.boulder.ibm.com"
type="cite">
<p><tt>Adam Young <a class="moz-txt-link-rfc2396E" href="mailto:ayoung@redhat.com"><ayoung@redhat.com></a> wrote on 10/19/2015
09:53:14 AM:</tt><br>
<tt>> While I tend to play up bug 968696 for dramatic
effect, the reality is <br>
> we have a logical contradiction on what we mean by
'admin' when talking <br>
> about RBAC.<br>
> <br>
> In early iterations of OpenStack, roles were global.
This is reflected <br>
> in many of the Policy checks that only look for the
global role. <br>
> However, prior to the Keystone-Light rewrite, role
assignments became <br>
> scoped to tenants. This shows up in the Keystone git
history. As this <br>
> pattern got established, some people wrote policy checks
that assert:<br>
> <br>
> role==admin and tenant_id=resource.tenant_id<br>
> <br>
> This contradicts the global-ness of the admin roles. If
I assign<br>
> ('joeuser', 'admin','mytenant') I've just granted them
the ability to <br>
> perform all of the admin operations.<br>
> <br>
> Thus, today we have a situation where, unless the user
rewrites the <br>
> default policy, they have to only assign the role admins
to users that <br>
> are trusted to be admins on the whole deployment.<br>
> <br>
</tt><br>
This all appears to be based on a misassumptions that a)
checking the project id should be done in policy.json files and
b) if it's not being checked in the policy file then it's not
being checked. Neither of those is the case. Many APIs check
project id in the code, which is where it should be checked.
Tokens are scoped to projects, thus any use of those tokens
should necessarily be scoped to the project... otherwise you're
not obeying the token scoping. The few places that are not
already enforcing that in their code need to be fixed to start
enforcing that. It doesn't make sense to do that in policy
files, since this is a hard and fast rule, not something someone
needs to be able to change in policy, or should be able to
change. Nor would it be practical to put this in policy files
when you realize that this logic applies to all roles, not just
admin.<br>
</p>
</blockquote>
<br>
I agree that project_id check is better performed in code. That is
not the issue here.<br>
<br>
Checking Project ID needs to be done, policy file or code does not
matter. The problem is more fundamental.<br>
<br>
0. All access is done with Keystone tokens. <br>
1. Admin is a role assigned on a project. Always.<br>
2. Some APIs have no project with which to check the Scope.<br>
3. We do not, today, have a means to communicate the scope for an
admin project.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:201510220916.t9M9GfXu021473@d03av04.boulder.ibm.com"
type="cite">
<p><br>
-Matthew<br>
<br>
<br>
</p>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>