yahoo-eng-team team mailing list archive

[Dmitrii Shcherbakov <1759120@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

# OS_USERNAME=user OS_USER_DOMAIN_NAME=admin_domain OS_PROJECT_NAME=admin 
# OS_PROJECT_DOMAIN_NAME=admin_domain
openstack user list --domain testdomain -> users returned for testdomain

# OS_USERNAME=user OS_USER_DOMAIN_NAME=testdomain OS_DOMAIN_NAME=testdomain + policy file modification
openstack user list --domain 49a912df2669410faecc6e0ab5d8dc80 -> users returned for testdomain
openstack user list --domain testdomain -> no users returned for testdomain

The same is valid for projects and roles. Role assignments have slightly
different policy rules in a sample file.

Environment: OpenStack Pike (UCA) + a slightly modified
https://github.com/openstack/keystone/blob/stable/pike/etc/policy.v3cloudsample.json
file:

https://paste.ubuntu.com/p/Zk7S7d7qm2/
    "admin_and_matching_domain_id": "rule:admin_required and (domain_id:%(domain_id)s or domain_name:%(domain_id)s)",

domain_name:%(domain_id)s - this was added to allow usage of --domain
<domain-name>, not just ID as documented, e.g. here
https://docs.openstack.org/python-openstackclient/pike/cli/command-
objects/user.html#cmdoption-user-create-domain ("--domain <domain>
Default domain (name or ID)")

https://paste.ubuntu.com/p/D35vMMbdTm/ - the first part of this is a
demonstration that a policy file is not enough to use --domain <domain-
name> without policy file modification in a non-admin project, the
second part is a demonstration of the problem after policy file
modification.

The domain_name is taken from auth_context and matched against domain_id
API call argument as described here
https://docs.openstack.org/keystone/pike/admin/identity-service-api-
protection.html

Debug mode traces for 3 different scenarios:
https://paste.ubuntu.com/p/8ntVt69tYy/


I can see that the whole Admin scoping and policy enforcement implementation is being reworked [0][1][2][3] and UUID tokens were deprecated in Pike so "domain_name" usage from auth context is not a reliable thing to do [4]. If my understanding is correct, please duplicate or "won't fix" this and let this be a reference for others to look at. Usage of --domain argument with a domain name instead of a domain_id is a bit inconsistent in how it's documented in OSC docs because it seems to only work for the admin user with admin project scoped tokens (provided that sample policy files are used).


[0] pad.lv/1750673
[1] https://review.openstack.org/#/c/526203/
[2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
[3] pad.lv/968696
[4] https://review.openstack.org/#/c/525325/

** Affects: keystone
     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/1759120

Title:
  Objects are not returned if domain name is used instead of domain id

Status in OpenStack Identity (keystone):
  New

Bug description:
  # OS_USERNAME=user OS_USER_DOMAIN_NAME=admin_domain OS_PROJECT_NAME=admin 
  # OS_PROJECT_DOMAIN_NAME=admin_domain
  openstack user list --domain testdomain -> users returned for testdomain

  # OS_USERNAME=user OS_USER_DOMAIN_NAME=testdomain OS_DOMAIN_NAME=testdomain + policy file modification
  openstack user list --domain 49a912df2669410faecc6e0ab5d8dc80 -> users returned for testdomain
  openstack user list --domain testdomain -> no users returned for testdomain

  The same is valid for projects and roles. Role assignments have
  slightly different policy rules in a sample file.

  Environment: OpenStack Pike (UCA) + a slightly modified
  https://github.com/openstack/keystone/blob/stable/pike/etc/policy.v3cloudsample.json
  file:

  https://paste.ubuntu.com/p/Zk7S7d7qm2/
      "admin_and_matching_domain_id": "rule:admin_required and (domain_id:%(domain_id)s or domain_name:%(domain_id)s)",

  domain_name:%(domain_id)s - this was added to allow usage of --domain
  <domain-name>, not just ID as documented, e.g. here
  https://docs.openstack.org/python-openstackclient/pike/cli/command-
  objects/user.html#cmdoption-user-create-domain ("--domain <domain>
  Default domain (name or ID)")

  https://paste.ubuntu.com/p/D35vMMbdTm/ - the first part of this is a
  demonstration that a policy file is not enough to use --domain
  <domain-name> without policy file modification in a non-admin project,
  the second part is a demonstration of the problem after policy file
  modification.

  The domain_name is taken from auth_context and matched against
  domain_id API call argument as described here
  https://docs.openstack.org/keystone/pike/admin/identity-service-api-
  protection.html

  Debug mode traces for 3 different scenarios:
  https://paste.ubuntu.com/p/8ntVt69tYy/

  
  I can see that the whole Admin scoping and policy enforcement implementation is being reworked [0][1][2][3] and UUID tokens were deprecated in Pike so "domain_name" usage from auth context is not a reliable thing to do [4]. If my understanding is correct, please duplicate or "won't fix" this and let this be a reference for others to look at. Usage of --domain argument with a domain name instead of a domain_id is a bit inconsistent in how it's documented in OSC docs because it seems to only work for the admin user with admin project scoped tokens (provided that sample policy files are used).

  
  [0] pad.lv/1750673
  [1] https://review.openstack.org/#/c/526203/
  [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
  [3] pad.lv/968696
  [4] https://review.openstack.org/#/c/525325/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1759120/+subscriptions