Open Stack

A new mail has been sent referencing horizon instead of victoria in the 
subject line. Consider this email solved

On 12/03/2021 12:30, Luke Camilleri wrote:
> 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
>>