[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