identity:list_services doesn't obey policy.yaml when scope enforcement is enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Magnum |
New
|
Undecided
|
Unassigned | ||
OpenStack Identity (keystone) |
New
|
Undecided
|
Douglas Mendizábal |
Bug Description
Using Openstack Xena with the following setting enabled in keystone:
[oslo_policy]
enforce_scope = true
I have two openstack cli sessions:
- system_admin: admin user scoped to system:all
- project_admin: admin user scoped to admin project
At first, I don't have list_services defined in policy.yaml, so it defaults to this:
- "identity:
As expected, system_admin can execute "openstack service list", and project_admin gets a Forbidden
I then change the policy.yaml definition to this, with the intent to remove the requirement for system:all ... which should allow the project_admin to run the command:
- "identity:
I run "openstack service list" again from both of the above cli sessions, and the result is the same as before. system_admin gets the list, and project_admin gets forbidden
I took a step further, and tried to remove permission requirements entirely ...
- "identity:
I run the command again, and the result is the same ... project_admin continues to get forbidden, which is odd because the policy no longer specifies any role requirements at all
At first I thought that perhaps policy.yaml changes are not registering in keystone for some reason. I ruled this out by temporarily breaking the permissions for another command that project_admin can use, and that worked.
This behavior looks like a bug at first glance, but I see no references to any rbac fixes in the release notes for any of the versions after Xena, so i have no confidence that an upgrade will affect this issue. In any case, i don't have a quick way to test this right now
Impact:
Why am I trying to change the permission of this command at all? The answer is Magnum. When I try to delete a cluster (that was created prior to enabling the rbac enforcement), magnum fails because it is unable to run the list_services command due to the permission error
- Unfortunately, magnum MUST be run in the project scope as clusters are tied to projects, and the catalog lacks orchestration endpoints when you are system_scoped
This puts me in a catch-22. I can't run magnum commands in system scope because orchestration endpoints are absent in the catalog, and I can't run magnum commands in project scope because of this rbac issue.
I was hoping to work around it by changing the permissions of the service command
I have attached many configs to this ticket, which should give you a sense of my openstack deployment. Any values/files missing should be assumed to be set to whatever the default is
Changed in keystone: | |
assignee: | nobody → Douglas Mendizábal (dougmendizabal) |
summary: |
- identity:list_services doesn't obey policy.yaml when enforcement is - enabled + identity:list_services doesn't obey policy.yaml when scope enforcement + is enabled |
I think this is a real bug.
I may be misreading the code, but it looks to me like the policy code checks the new rule from policy.yaml for auth but also does a separate scope check -- the scope check seems to only use the original rule from code rather than the rule from policy.yaml. So you can only override policies in policy.yaml as long as you don't modify the scope requirements.
This breaks quite a lot of things!