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