Public bug reported: ## 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. ** 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/2041611 Title: GET /v3/domains returns all domains even in domain scope Status in OpenStack Identity (keystone): New 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 -- 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
