yahoo-eng-team team mailing list archive

[OpenStack Infra <2041611@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/keystone/+/900028
Committed: https://opendev.org/openstack/keystone/commit/dd785ee692118a56ea0e3aaaf7f5bd6c73ea9c91
Submitter: "Zuul (22348)"
Branch:    master

commit dd785ee692118a56ea0e3aaaf7f5bd6c73ea9c91
Author: Markus Hentsch <markus.hentsch@xxxxxxxxxxxxx>
Date:   Fri Nov 3 10:43:34 2023 +0100

    Add domain scoping to list_domains
    
    Introduces domain-scoped filtering of the response list of the
    list_domains endpoint when the user is authenticated in domain scope
    instead of returning all domains. This aligns the implementation with
    other endpoints like list_projects or list_groups and allows for a
    domain-scoped reader role.
    Changes the default policy rule for identity:list_domains to
    incorporate this new behavior for the reader role.
    
    Closes-Bug: 2041611
    Change-Id: I8ee50efc3b4850060cce840fc904bae17f1503a9


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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/2041611

Title:
  GET /v3/domains returns all domains even in domain scope

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  ## Summary

  The `GET /v3/domains` endpoint's returned domain list is not filtered if a domain-scoped authentication is used to access it. Instead it returns all domains.
  In case domain names have relations to tenants/customers, any policy model that allows tenants to list domains will expose other tenants' identities.

  In contrast, endpoints like `GET /v3/projects` and `GET /v3/groups`
  implement proper domain scoping. For further technical analysis how
  those endpoints achieve this, see here:
  https://github.com/SovereignCloudStack/issues/issues/446#issuecomment-1775095749

  ## Steps to reproduce

  The following steps have been recorded using an unmodified DevStack
  environment.

  First consider the following adjustment to
  `/etc/keystone/policy.yaml`:

  ```
  identity:list_domains: role:member or rule:admin_required
  ```

  ... so that users with the `member` role may access `GET /v3/domains`
  for illustration purposes.

  Next, create additional domains and a domain member:

  ```
  openstack domain create domain2
  openstack domain create domain3
  openstack user create --domain domain2 --password "foobar123%" domain2-user
  openstack role add --user domain2-user --domain domain2 member
  ```

  Finally, create an openrc file for the domain member to have it issue
  a domain-scoped token:

  ```
  source stackrc
  export OS_REGION_NAME=RegionOne
  export OS_AUTH_URL=http://$HOST_IP/identity
  export OS_IDENTITY_API_VERSION=3
  export OS_USERNAME=domain2-user
  export OS_AUTH_TYPE=password
  export OS_USER_DOMAIN_NAME=domain2
  export OS_DOMAIN_NAME=domain2
  export OS_PASSWORD=foobar123%
  unset OS_PROJECT_NAME  
  unset OS_TENANT_NAME
  unset OS_PROJECT_DOMAIN_NAME
  unset OS_PROJECT_DOMAIN_ID
  unset OS_USER_DOMAIN_ID
  ```

  (this example is based on a DevStack environment)

  Now the following happens when the domain member user is accessing the
  domain list:

  ```
  $ source domain-member.openrc

  $ openstack domain list
  +----------------------------------+---------+---------+--------------------+
  | ID                               | Name    | Enabled | Description        |
  +----------------------------------+---------+---------+--------------------+
  | 1a1a793377464131a2744e27fec9bcdf | domain2 | True    |                    |
  | 449167ed506c43cea43b997a1f345606 | domain3 | True    |                    |
  | default                          | Default | True    | The default domain |
  +----------------------------------+---------+---------+--------------------+
  ```

  Although the token of the domain member user making the API request is strictly domain-scoped, all domains are returned.
  In case domain names would somehow be related to other tenants' identities, these would get exposed this way.

  ## Notes

  This is not an issue with Keystone's default policy configuration
  since only admins may access the `GET /v3/domains` endpoint at all and
  those have access to all domains anyway.

  Only unlocking `GET /v3/domains` for other roles will make this
  undesired behavior possible.

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