Open Stack

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
>
>