yahoo-eng-team team mailing list archive

[Dmitry Veber <2017056@xxxxxxxxxxxxxxxxxx>]

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