Open Stack

Adam Young <ayoung at redhat.com> wrote on 10/22/2015 10:31:12 AM:
> On 10/22/2015 05:16 AM, William M Edmonds wrote:
> Adam Young <ayoung at redhat.com> wrote on 10/19/2015 09:53:14 AM:
> > While I tend to play up  bug 968696 for dramatic effect, the reality is

> > we have a logical contradiction on what we mean by 'admin' when talking

> > about RBAC.
> >
> > In early iterations of OpenStack, roles were global.  This is reflected

> > in many of the Policy checks that only look for the global role.
> > However, prior to the Keystone-Light rewrite, role assignments became
> > scoped to tenants.  This shows up in the Keystone git history.  As this

> > pattern got established, some people wrote policy checks that assert:
> >
> >       role==admin and tenant_id=resource.tenant_id
> >
> > This contradicts the global-ness of the admin roles.  If I assign
> > ('joeuser', 'admin','mytenant') I've just granted them the ability to
> > perform all of the admin operations.
> >
> > Thus, today we have a situation where, unless the user rewrites the
> > default policy, they have to only assign the role  admins to users that

> > are trusted to be admins on the whole deployment.
> >
>
> 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.
>
> I agree that project_id check is better performed in code.  That is
> not the issue here.
>
> Checking Project ID needs to be done, policy file or code does not
> matter.  The problem is more fundamental.
>
> 0. All access is done with Keystone tokens.
> 1. Admin is a role assigned on a project. Always.
> 2. Some APIs have no project with which to check the Scope.

if the URI of the API doesn't include the project, then the code should
limit the request to the scope of the token. No need to check that the
scope of the token matches the scope of the API because scope wasn't
indicated on the API, i.e. scope is implicit based on the token.

> 3. We do not, today, have a means to communicate the scope for an
> admin project.

I don't know what you mean here. "Scope for an admin project"? The scope of
a project is the things that are in that project. And admin is a role that
can exist on any project per #1, i.e., there is no "admin project". We may
need to create the concept of an admin project for keystone in order to
address 968696, but that would be a keystone concept and irrelevant to
nova, cinder, etc.

-matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151023/2cb4ae58/attachment.html>