Domain admin can see all domains and projects with openstack client

[Eric Miller]

Environment
Deployed using Kolla-ansible version 7.0.0.0b2 in VMs on ESXi 5.5 (same problem occurs on Queens release)
3 controllers and various other VMs for other roles (22 in total)

Parameters:
Default policy.json configuration - no override files, such as policy.v3cloudsample.json, however using this policy file on the Keystone nodes makes no difference, after changing the "admin_domain_id" to "default".

Commands run:
(export variables set for admin user)
domain create TestDomain
project create --domain TestDomain TestDomainProject
user create --domain TestDomain --password test TestDomainAdmin
role add --project-domain TestDomain --project TestDomainProject --user TestDomainAdmin admin

(export variables set to TestDomainAdmin user's domain and project - openstack client run again)
(openstack) domain list
+----------------------------------+------------------+---------+-------------------------------------------+
| ID | Name | Enabled | Description |
+----------------------------------+------------------+---------+-------------------------------------------+
| 7a44fa16d42443c1b531af2447d7cd3f | TestDomain | True | |
| c4ce448b93a949b78a8feea567f210b4 | heat_user_domain | True | |
| default | Default | True | The default domain |
| e082d7aefb314041b89bb3311836d721 | magnum | True | Owns users and projects created by magnum |
+----------------------------------+------------------+---------+-------------------------------------------+
(openstack) project list
+----------------------------------+-------------------+
| ID | Name |
+----------------------------------+-------------------+
| 371b28700a06462b8fd52fa95e733a0a | admin |
| 3a526ae9a3874ab4a645cc24ad7beff2 | TestDomainProject |
| 5abb3ac26dae4d25830b43afd62b74ff | service |
+----------------------------------+-------------------+

Issue:
Horizon interface properly shows only the TestDomainProject project and no Domains tab, which is correct. The API that the openstack client uses is returning root-level information as shown above, such as other domain's projects as well as every domain.

Am I missing something, or is this a bug?

Thanks!

Eric

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Jeremy Stanley (fungi)]

Could this report be a duplicate of OSSA-2018-002? https://security.openstack.org/ossa/OSSA-2018-002.html

[Eric Miller (erickmiller)]

I looked into this quite a bit tonight and it looks like this was a misunderstanding on my part of how a Domain Admin should be defined - specifically without a default project defined for the Domain Admin user. Correct me if I'm wrong, though.

It does not explain the difference I saw between Horizon's access controls and the OpenStack CLI, though.

This is an example of what I used to successfully create a Domain Admin account that does NOT have access to see other projects or domains:

# Run as Cloud Admin
domain create TestDomain
user create --domain TestDomain --password test TestDomainAdmin
role add --domain TestDomain --user TestDomainAdmin admin

I can then create a project with this user as well as a user associated with the project in the new domain:

# Run as Domain Admin - logged-in using domain-scoped token with the OpenStackClient
# Must specify domain ID, not domain name (authorization error otherwise)?
project create --domain 492537d206754d0b9ccde50067df6d03 TestProject
project list --domain 492537d206754d0b9ccde50067df6d03
user create --domain 492537d206754d0b9ccde50067df6d03 --password test TestDomainUser
role add --domain 492537d206754d0b9ccde50067df6d03 --user e207992708c1426faa21779c730f73d1 _member_
role add --project 59c88317254044d6956b88255d16cc11 --user e207992708c1426faa21779c730f73d1 _member_

Eric

[Lance Bragstad (lbragstad)]

Hi Eric,

This looks like it's related to a long-standing, and unfortunately public bug (https://bugs.launchpad.net/keystone/+bug/968696). This bug has side-effects across several services, not just keystone, making the fix complex to orchestrate across services.

We do have a set of enhancements to keystone and oslo libraries that should provide the necessary tooling to address these gaps across OpenStack services [0]. I've addressed specific gaps within keystone's API in separate bug reports [1]. There is one bug report [2] that is closely related to what you've described here.

Keystone is undergoing a major overhaul to make addressing these types of issues easier. We're planning to address those bugs in Stein (given the point we're at with the Rocky release).

[0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[1] https://bugs.launchpad.net/keystone/+bugs?field.tag=policy
[2] https://bugs.launchpad.net/keystone/+bug/1750673

[Eric Miller (erickmiller)]

Thank you Lance! That bug (https://bugs.launchpad.net/keystone/+bug/968696) is definitely a "long" bug report. :)

We thankfully have a workaround as I described - when a user is assigned the "admin" role for a domain, the user is scoped to only perform actions within this domain - specifically without defining a default project for this user:

domain create TestDomain
user create --domain TestDomain --password test TestDomainAdmin
role add --domain TestDomain --user TestDomainAdmin admin

The issue we have, at this point, is the lack of domain quotas. Maybe this will be solved with Unified Limits (I think this might be what you were referring to with regards to some changes in Stein?).

I'll review the Stein specs and bugs you linked and will keep track of this process so we can test here.

Thanks again!

Eric

[Jeremy Stanley (fungi)]

Thanks, Lance. Should we consider this report a duplicate of bug 1750673 in that case? Seems at a minimum there's no point in keeping it private at least.

[Morgan Fainberg (mdrnstm)]

I would consider it a duplicate of bug #968696

[Lance Bragstad (lbragstad)]

I would agree that this is certainly a duplicate of bug 968696, but I would be fine using bug 1750673 (maybe just linking it here is enough though). Using bug 968696 might be more complete from a context perspective, though.

Eric,

The unified limits API is still relatively fresh and marked as experimental. We do plan to take the same approach with limits as we do with the rest of the bugs tagged with `policy` in keystone bug tracker. It should honor the same scoping we plan to implement elsewhere. Hopefully this helps.

[Jeremy Stanley (fungi)]

Given feedback from Morgan and Lance, I'm switching this to a public bug report and duplicate of 968696. Once it's public, anyone who disagrees as to which bug it's actually a duplicate of is certainly able to alter that.

[Lance Bragstad (lbragstad)]

I should add that the entire context of the problem described in bug 968696 is extremely dense, even for people seasoned with the project and subject area.

That said, I tried to document the approach and reasoning behind the solution we came up with a few cycles ago (hopefully as a way to keep us on target). Those documents were merged as high-level docs in our specifications repository to make it easier for people to understand how we plan to fix these issues.

http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals.html
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-security-roadmap.html