[openstack-dev] [cross-project] "Admin" ness not properly scoped

Adam Young ayoung at redhat.com
Thu Jul 23 18:05:54 UTC 2015

On 07/23/2015 01:11 PM, melanie witt wrote:
> On Jul 23, 2015, at 7:35, Adam Young <ayoung at redhat.com> wrote:
>> What this means is the if a user is assigned "admin" on any project, they are assigned admin for everything.
>> Fixing this is going to require a change to how we write policy.
>> Each policy rule needs to have two parts:
>> 1.  Match the scoped of the token (project for everything that is not Keystone, project or domain for Keystone).
>> 2.  Match the role.
> Thanks for bringing this up. If I understand correctly, you're saying we can fix this by modifying policy.json alone, right? There aren't any code changes required?
Unless you need to fetch an object out of the database in order to get 
its project id, and you are not currently doing that, policy enforcement 
as currently implemented should be OK.

On the quota API,  we might acutally need to rethink this;  the role 
that  user gets that allows them to set quota should not be on the 
project itself, but on the containing project.  That information might 
not yet be made available.

What makes quota's different than other things like this is that a quota 
is not something managed *by* the project but instead something external 
managed *on* the project.

> So far, for me it has worked fine for "admin" role to grant "admin" everywhere for the system administrators (no one else has "admin" role). But with the prospect of nested quota in nova, I think we would have a new rule for quota update that is, for example:
> "quota_admin_rule": "role:quota_admin and project_id:%(project_id)s"
> "admin_or_quota_admin": "role:admin or rule:quota_admin_rule"

  ordinarily the rule should be something like

"quota_admin_rule": "(role:quota_admin or role.admin) and project_id:%(project_id)s"

But that means that the user would have the quota_admin on the project 
itself.  That is improperly scoped;  if I am an admin on that project, I 
should not be able to set quota on that project. The rule should be:

"quota_admin_rule": " parent.project_id:%(project_id)s and (role:admin or role:quota_admin)",

I would prefer:

quota_admin_role: "(role:admin or role:quota_admin)"
quota_scope: " parent.project_id:%(project_id)s"

"compute_extension:quotas:update": "rule:quota_scope and rule:quota_admin_role",

Knowing that a deployer should be able to update the role portion, but not the scope

> "compute_extension:quotas:update": "rule:admin_or_quota_admin",
> "compute_extension:quotas:delete": "rule:admin_or_quota_admin",
> "os_compute_api:os-quota-sets:update": "rule:admin_or_quota_admin",
> "os_compute_api:os-quota-sets:delete": "rule:admin_or_quota_admin",
> "os_compute_api:os-quota-sets:detail": "rule:admin_or_quota_admin",
> if I want system administrators and designated quota administrators of a project to be able to update quota. In keystone the quota admins will have the role "quota_admin" only in their projects.
> Is that an example of the right way to scope "admin" in your view?
> -melanie (irc: melwitt)
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/60c33ad0/attachment.html>

More information about the OpenStack-dev mailing list