On 07/23/2015 01:11 PM, melanie witt wrote:
On Jul 23, 2015, at 7:35, Adam Young <ayo...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
