Keystone enforced policy issues - Victoria

Luke Camilleri luke.camilleri at zylacomputing.com
Thu Mar 11 21:39:05 UTC 2021


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