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¶

OpenStack Victoria and Yoga have two sets of default policies for each of its services:

Legacy default policies
With these policies, the role of administrator in any context grants the user global admin access to the given service. Any other role in the project grants the user normal access, enabling the user to create resources as well.
New default policies
These policies are written based on the possibilities of the updated version of OpenStack Keystone. They take into account the hierarchical default roles, such as reader, member, and admin, and the system scope.

Warning

Mirantis does not recommend using the new default policies at the moment. Our testing results indicate that this set of policies is not consistently reliable across all services. Moreover, as of the OpenStack Yoga release, the new default policies have not undergone extensive testing in the upstream development.

Enforcing or utilizing these new default policies may result in unexpected consequences for the functionality of your MOSK deployment affecting its LCM operations, such as running Tempest tests or automatic live migrating of instances during node maintenance.

Changes to upstream default policies in MOSK¶

MOSK deploys OpenStack with some policies already customized. The list of such policies includes:

[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 that performs automatic instance live migrations during node maintenance.

This role enables the service user to live migrate instances that use encrypted volumes. By upstream defaults, only the user who created the secret or the admin of the corresponding project can decode a secret.