[keystone][ops]Keystone enforced policy issues - Victoria
Luke Camilleri
luke.camilleri at zylacomputing.com
Fri Mar 12 11:30:15 UTC 2021
Updated subject with tags
On 11/03/2021 22:39, Luke Camilleri wrote:
> Hi there, we have been troubleshooting keystone policies for a couple
> of days now (Victoria) and would like to reach out to anyone with some
> experience on the keystone policies. Basically we would like to follow
> the standard admin, member and reader roles together with the scopes
> function and have therefore enabled the below two option in keystone.conf
>
> enforce_scope = true
> enforce_new_defaults = true
>
> once enabled we started seeing the below error related to token
> validation in keystone.log:
>
> 2021-03-11 19:50:12.009 1047463 WARNING
> keystone.server.flask.application
> [req-33cda154-1d54-447e-8563-0676dc5d8471
> 020bd854741e4ba69c87d4142cad97a5 c584121f9d1a4334a3853c61bb5b9d93 -
> default default] You are not authorized to perform the requested
> action: identity:validate_token.: keystone.exception.ForbiddenAction:
> You are not authorized to perform the requested action:
> identity:validate_token.
>
> The policy was previously setup as:
>
> identity:validate_token: rule:service_admin_or_token_subject
>
> but has now been implemented with the new scope format to:
>
> identity:validate_token: (role:reader and system_scope:all) or
> rule:service_role or rule:token_subject
>
> If we change the policy to the old one, we stop receiving the
> identity:validate_token exception. This only happens in horizon and
> running the same commands in the CLI (python-openstack-client) does
> not output any errors. To work around this behavior we place the old
> policy for validate_token rule in
> /usr/share/openstack-dashboard/openstack_dashboard/conf/keystone_policy.yaml
> and in the file /etc/keystone/keystone.conf
>
> A second way how we can solve the validate_token exception is to
> disable the option which has been enabled above "enforce_new_defaults
> = true" which will obviously allow the deprecated policy rules to
> become effective and hence has the same behavior as implementing the
> old policy as we did
>
> We would like to know if anyone have had this behavior and how it has
> been solved maybe someone can point us in the right direction to
> identify better what is going on.
>
> Last but not least, it seems that from Horizon, the admin user is
> being assigned a project scoped token instead of a system scoped
> token, while from the CLI the same admin user can successfully issue a
> system:all token and run commands across all resources. We would be
> very happy to receive any form of input related to the above issues we
> are facing
>
> Thanks in advance for any assistance
>
More information about the openstack-discuss
mailing list