Public bug reported:
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:list_services": "role:reader and system_scope:all"
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:list_services": "role:reader"
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:list_services": ""
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
** Affects: keystone
Importance: Undecided
Status: New
** Affects: magnum
Importance: Undecided
Status: New
** Attachment added: "etc.zip"
https://bugs.launchpad.net/bugs/2017056/+attachment/5665349/+files/etc.zip
** Also affects: magnum
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2017056
Title:
identity:list_services doesn't obey policy.yaml when enforcement is
enabled
Status in OpenStack Identity (keystone):
New
Status in Magnum:
New
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:list_services": "role:reader and system_scope:all"
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:list_services": "role:reader"
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:list_services": ""
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2017056/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
