yahoo-eng-team team mailing list archive

[Markus Hentsch <2041611@xxxxxxxxxxxxxxxxxx>]

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