OpenStack API access policies¶

OpenStack provides operators with fine-grained control over access to API endpoints and actions through access policies. These policies allow cloud administrators to restrict or grant access based on roles and the current request context, such as the project, domain, or system.

OpenStack services come with a set of default policy rules that are generally sufficient for most users. However, for specific use cases, these policies may need to be modified.

MOSK enables you to define custom policies through the OpenStackDeployment custom resource. For configuration details, refer to features:policies.

New and legacy defaults¶

Since the Victoria release, OpenStack has effectively maintained two sets of default policies for each of its services.

Legacy default policies¶

With the legacy default policies, only the admin role has a dedicated meaning. Granting this role to a user in any context provides global administrative access to the service APIs.

Any other role within the project grants the user standard access, enabling them to create resources as well.

New default policies¶

The new default policies are based on the enhanced capabilities of updated OpenStack Keystone. They incorporate the hierarchical default roles, such as reader, member, and admin, as well as system scope.

How both sets of default policies work together¶

If a policy rule is explicitly defined by the deployment or by the cloud operator through the OpenStackDeployment custom resoruce, only that rule is enforced.

If no explicit API access rule is set, MOSK applies both the legacy and new policy sets simultaneously. Each API access request is checked by both sets, and access is granted if either of the policy sets allows it. This behavior is controlled by the [oslo_policy] enforce_new_defaults configuration option, which is set individually for each OpenStack service. Setting this option to True ensures that API access to this service is evaluated only against the new default policies.

Caution

Mirantis does not recommend enforcing the new default policies.

Our test results indicate that these policies are not yet consistently reliable across all services. Additionally, as of the OpenStack Antelope release, the new default policies have not undergone extensive testing in the upstream development.

Enforcing or using the new default policies may lead to unexpected consequences potentially affecting LCM operations such as running Tempest tests, performing automatic live migrations during node maintenance, and so on.

Changes to upstream default policies in MOSK¶

MOSK deploys OpenStack with certain upstream policies customized and additional fine-grained policies that are not present in upstream. The following list provides details on these policies.

Barbican¶

The global-secret-decoder role¶

A user with this role can decode any Barbican secret in any project.

This role is specifically granted to the service user performing automatic instance live migrations during node maintenance. Granting this role to the service user enables them to live migrate instances that use encrypted volumes.

By default, upstream policies restrict secret decryption to either user who created the secret or the administrator of the corresponding project.

A user that created an order can also delete that order¶

Available since MOSK 23.1

A user can automatically clean up orders, preventing them from accumulating and causing the Barbican database to grow uncontrollably.

By default, upstream policies allow a user with the creator role to create orders. However, they restrict order deletion to the project administrator.

Nova¶

Non-admins can cold-migrate instances without specifying the destination host¶

Available since MOSK 24.3

Refer to Instance migration for details.

By default, upstream policies restrict cold migrations to administrative users only.

Non-admins can live-migrate instances without specifying the destination host¶

Available since MOSK 24.3

Refer to Instance migration for details.

By default, upstream policies restrict live migration to administrative users only, without the ability to distinguish between different types of live migration.

Per-tag server tag policies¶

Available since MOSK 25.1

A cloud operator can define flexible rules to control assignment and removal of specific server tags to and from OpenStack instances. These rules allow the operator to restrict tag assignment and removal based on their value.

Per-tag server tag policies include the following:

os_compute_api:os-server-tags:update:{tag_name}
Restricts access to the APIs for creating instances, adding tags, and replacing tags
os_compute_api:os-server-tags:delete:{tag_name}
Restricts access to the APIs for deleting a single tag, deleting all tags, and replacing existing tags

For example, to ensure that only administrators can exclude specific instances from migration by the DRB service, the operator can configure the following policies through the OpenStackDeployment custom resource:
kind: OpenStackDeployment spec: features: policies: nova: os_compute_api:os-server-tags:update:lcm.mirantis.com:no-drb: rule:admin_api os_compute_api:os-server-tags:delete:lcm.mirantis.com:no-drb: rule:admin_api