Application credentials do not take account of implied roles

[Andrew Bonney]

Keystone 2023.1 a72ec5d

We have recently added an implied role linking our original '_member_' role to the Keystone default 'member' role. This works well for standard user accounts, but where application credentials were originally created with the '_member_' role, they are unable to do things which require 'member' or 'reader' permission. I assume the same would be true in a fresh deployment if an application credential was created with the 'member' role, in that it would be prevented from doing things which require 'reader' permission.

It appears this issue was originally alluded to in https://bugs.launchpad.net/keystone/+bug/1773967/comments/4, but perhaps wasn't fixed when the rest of that issue was tackled, or maybe it has re-occurred.

I've compared logs seen in services such as Nova which show a full complement of roles when a full user attempts actions (_member_, member and reader), but when an application credential created by that user is used this list shows just '_member_'. Similarly having added some debug logging around https://github.com/openstack/keystone/blob/1ac30ab59ffe272a1c6af5a04298d2fb55db4e15/keystone/models/token_model.py#L444 which was added in the issue above the same is true, and only '_member_' is returned.

As we wouldn't expect average users to have knowledge of which roles implied which others so that they could apply a full list when creating application credentials, I assume this isn't expected behaviour?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/keystone/+/893737

[Andrew Bonney (andrewbonney)]

I've added a proof of concept in https://review.opendev.org/c/openstack/keystone/+/893737 for a fix. I'd suggest this needs more work before it's worthy of merging, but gives us a workaround.

Whilst I'm not familiar with all of the tokens that get processed here, a brief scan of the methods and those which do or don't take account of implied roles seems to suggest the following:

_get_system_roles -> OK
_get_trust_roles -> OK
_get_oauth_roles (builds on _get_project_roles) -> OK

_get_federated_roles -> NOT OK
_get_domain_roles -> NOT OK
_get_project_roles -> NOT OK
_get_application_credential_roles -> NOT OK
_get_oauth2_credential_roles (builds on _get_project_roles) -> NOT OK

The extent to which this is intentional I'm not sure, but it does feel like there's a bit of repetition here and the best fix might involve some refactoring and some tests for each token type's behaviour with implied roles.

[Andrew Bonney (andrewbonney)]

The previous comment can be ignored. I missed that https://opendev.org/openstack/keystone/src/branch/master/keystone/assignment/core.py#L865 mostly deals with implied roles for all of the above. The issue in the application credentials case as it stands is that this returned list is filtered after the implied roles are added, which the patch works around in a similar way to _get_oauth_roles.

[Debasis (debamondal)]

I'm facing the same issue. I've kolla-ansible deployment. Any timeline for when it will be resolved? What I observe is that openrc file created with app creds with member, reader roles or any implied roles of these two cannot list servers. Is it expected behaviour?

[Sam Schmitt (samcat116)]

I'm also facing this issue in a new Bobcat deployment.

[Sam Morrison (sorrison)]

Yeah this is a big issue, glance has changed policy to only allow reader role to list images.
Now all the app-creds with member role can't list image.