search

osism / issues

This repository is used for bug reports that are cross-project or not bound to a specific repository (or to an unknown repository).
https://www.osism.tech
1 stars 1 forks source link

oslo_policy: set enforce_new_defaults & enforce_scope to true as standard for new installations #269

Open costelter opened 2 years ago

costelter commented 2 years ago

Since the Ussuri release the default settings for the oslo_policy handling for enforce_new_defaults and enforce_scope is set to false. So new installations will be unable to make use of "richer access management" (like read-only access for example).

Support for scope types and additional roles in the default nova policies, allowing for richer access management including the ability to configure read-only access to resources. This feature is disabled by default. See the Policy Concepts documentation for more details.

This is still valid for the Xena release.

So we would like to see that new installations will get this enabled by default.

[oslo_policy]
enforce_new_defaults = True
enforce_scope = True

Scope

Each policy is protected with appropriate scope_type. Nova support two types of sope_type with their combination. ['system'], ['project'] and ['system', 'project'].

To know each policy scope_type, please refer the Policy Reference

This feature is disabled by default can be enabled via config option [oslo_policy]enforce_scope in nova.conf

New Defaults(Admin, Member and Reader)

Policies are default to Admin, Member and Reader roles. Old roles are also supproted. You can switch to new defaults via config option [oslo_policy]enforce_new_defaults in nova.conf file.

berendt commented 2 years ago

Makes sense for me.

For the moment you can place the mentioned parameters in the global.conf configuration file in environments/kolla. This way those parameters will be used by all OpenStack services.

berendt commented 6 months ago

Related to https://github.com/SovereignCloudStack/standards/pull/585.

markus-hentsch commented 6 months ago

Please note that those options have severe implications right now^1 and are still not enabled per default in the latest upstream release^2 (2024.1 as the time of writing this) for a reason.

Most importantly they seem to break orchestration tooling such as Heat^1. Since SCS aims to add Heat to the list of officially supported services^3 this can be problematic.

As linked by @berendt above they would also currently break the Domain Manager role which will need to stay SCS-specific and incompatible to those options until we conclude its upstream integration^4, because there are limits on how far we can go without touching Keystone's source code.