Open Stack

Dear Akihiro, thanks a lot for your input, we will wait for such 
projects to progress further until we take the scoped tokens approach then.

In the meantime we will revert to the deprecated (original) json rules 
and deploy the policy.v3cloudsample.json so that we could add two new 
roles (cloud_admin and project_admin)

Thanks once again

On 16/03/2021 01:33, Akihiro Motoki wrote:
> Hi,
>
> Horizon does not support the system-scoped token yet as of Victoria
> and coming Wallaby.
>
> Horizon talks with various services. Some services support the
> system-scoped token and
> some do not. It is not easy to handle such kind of mixed situations.
> As of Victoria, keystone and nova support the system-scoped token but
> other services do not.
> We can fall back to the project-scoped token with admin role, but many
> considerations are
> still needed. This is the reason of the slow progress in horizon.
>
> Victoria horizon also does not understand deprecated policy rules
> defined as policy-in-code.
> This was addressed in Wallaby, so we can use the same version of
> policy.yaml in keystone and horizon.
> However, horizon still does not handle the system-scoped token and
> horizon still depends on
> deprecated rules (rather than the system-scope aware rules).
> The horizon team recognizes this is the most important feature gap and
> will do the best to address it in Xena cycle.
>
> Thanks,
> Akihiro Motoki (irc: amotoki)
>
> On Tue, Mar 16, 2021 at 8:02 AM Luke Camilleri
> <luke.camilleri at zylacomputing.com> wrote:
>> Hi Everyone, we had sent an email to this mailing list last week on an
>> issue that we are having which we thought was being generated by
>> keystone but on closer inspection it seems that this is coming actually
>> from Horizon policy files.
>>
>> We would like to implement OpenStack using the scope based approach (v3)
>> so that we could keep the main roles (reader,member and Admin) and use
>> the scopes to differentiate the targets.
>>
>> We have implemented the below settings in /etc/keystone/keystone.conf:
>>
>> enforce_scope = true
>> enforce_new_defaults = true
>>
>> All works well with the cli and the scopes except Horizon. We constantly
>> receive errors in /var/log/keystone.log like:
>>
>> 2021-03-15 23:15:55.772 1611435 WARNING
>> keystone.server.flask.application
>> [req-a89277a2-8fb2-4fcb-b337-e76a73bb3af9
>> 1405ecf1ff7f4e4188648dbd1fb84c07 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
>>
>> but the same command (for example an "openstack domain list") works well
>> from the CLI.
>>
>> We could identify the issue coming from the policy files shipped with
>> the dashboard at /etc/openstack-dashboard/<policies.json> as the rules
>> within these policies are not scope based and in json format while
>> according to the roadmap it seems that yaml is being used for the policy
>> files and they should be scope based.
>>
>> When we try to convert the files to json to then upgrade them (to use
>> the scope syntax) we receive the following errors:
>>
>> #oslopolicy-convert-json-to-yaml --config-file
>> /etc/keystone/keystone.conf --namespace keystone --output-file
>> keystone_policy.yaml --policy-file keystone_policy.json
>> Traceback (most recent call last):
>>     File "/bin/oslopolicy-convert-json-to-yaml", line 10, in <module>
>>       sys.exit(convert_policy_json_to_yaml())
>>     File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py",
>> line 599, in convert_policy_json_to_yaml
>>       conf.output_file)
>>     File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py",
>> line 451, in _convert_policy_json_to_yaml
>>       scope_types=default_rule.scope_types)
>>     File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line
>> 1239, in __init__
>>       scope_types=scope_types
>>     File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line
>> 1154, in __init__
>>       self.description = description
>>     File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line
>> 1251, in description
>>       raise InvalidRuleDefault('Description is required')
>> oslo_policy.policy.InvalidRuleDefault: Invalid policy rule default:
>> Description is required.
>>
>> We believe that converting such files to yaml and then upgrading them
>> for scope based access (v3) should solve our issues based on the fact
>> that if we disable the enforce _scope and enforce_new_defaults we can
>> have a fully functional setup (but not scope based) which defies the
>> initial objective
>>
>> Thanks in advance for anyone that may be able to assist with this issue
>>
>>