Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Chapter 5. Policy Management

5.1. Using policy files for access control
リンクのコピー

Each OpenStack service contains resources that are managed by access policies. A resource could include functions such as:

  • Permission to create and start instances.
  • The ability to attach a volume to an instance.

The default policies can be viewed by generating a report for each service: 

$ oslopolicy-policy-generator --namespace nova
Copy to Clipboard Toggle word wrap

You can override the default rules by editing the policy.json file allocated to each OpenStack service. For example, the Compute service will have a policy.json in the nova directory (note that the exact file path might vary for containerized services). By modifying the service’s policy.json file, you are overriding the default policy in its entirety. This means that any required admin permissions must also be redefined.

Note

You will need to check that any changes to the access control policies do not unintentionally weaken the security of any resource. In addition, any changes to a policy.json file become effective immediately and do not require the service to be restarted.

5.1.1. Example: Create a Power User role
リンクのコピー

You can customize the permissions assigned to a keystone role by updating a service’s policy.json file. This allows them to more granularly define the permissions assigned to a class of users. This example creates a power user role for your deployment with the following privileges:

  • Start an instance.
  • Stop an instance.
  • Manage the volumes that are attached to instances.

The intention behind this role is to grant additional permissions to certain users, without needing to grant then admin access. To use these privileges, you will need to grant the following to a custom role:

  • Start an instance: "os_compute_api:servers:start": "role:PowerUsers"
  • Stop an instance: "os_compute_api:servers:stop": "role:PowerUsers"
  • Configure an instance to use a particular volume: "os_compute_api:servers:create:attach_volume": "role:PowerUsers"
  • List the volumes attached to an instance: "os_compute_api:os-volumes-attachments:index": "role:PowerUsers"
  • Attach a volume: "os_compute_api:os-volumes-attachments:create": "role:PowerUsers"
  • View the details of an attached volume: "os_compute_api:os-volumes-attachments:show": "role:PowerUsers"
  • Change the volume attached to an instance: "os_compute_api:os-volumes-attachments:update": "role:PowerUsers"
  • Delete a volume attached to an instance: "os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
Note

By modifying the policy.json file, you are overriding the default policy. As a result, members of PowerUsers will be the only users able to perform these actions. You can allow admin users to retain these permissions by creating a rules for admin_or_power_user. You can also use some basic conditional logic here to say role:PowerUsers or role:Admin.

  1. Be sure that your command line session is using the keystone v3 API. This means sourcing a rc file with the v3 endpoint and settings defined. For example: 

    OS_AUTH_URL=http://controller-hostname.lab.local:5000/v3
OS_USERNAME=username
OS_PASSWORD=password
OS_USER_DOMAIN_NAME=Default
OS_PROJECT_DOMAIN_NAME=Default
OS_PROJECT_NAME=project-name
OS_IDENTITY_API_VERSION=3
    Copy to Clipboard Toggle word wrap

  2. Create the custom keystone role: 

    $ openstack role create PowerUsers
+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| domain_id | None                             |
| id        | 7061a395af43455e9057ab631ad49449 |
| name      | PowerUsers                      |
+-----------+----------------------------------+
    Copy to Clipboard Toggle word wrap

  3. Add an existing user to the role, and assign the role to a project: 

    $ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
    Copy to Clipboard Toggle word wrap
    Note

    A role assignment is paired exclusively with one project. This means that when you assign a role to a user, you will also define the target project at the same time. If you want the user to receive the same role but for a different project, you will need to assign the role to them again separately but targeting the different project.

  4. View the default nova policy settings: 

    $ oslopolicy-policy-generator --namespace nova
    Copy to Clipboard Toggle word wrap

  5. Create custom permissions for the new PowerUsers role by adding these entries to /etc/nova/policy.json:

    Note

    You should test your policy changes before deployment. This will help you determine if they are working as expected. 

    {
"os_compute_api:servers:start": "role:PowerUsers",
"os_compute_api:servers:stop": "role:PowerUsers",
"os_compute_api:servers:create:attach_volume": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:index": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:create": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:show": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:update": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
}
    Copy to Clipboard Toggle word wrap

    Once you save this file, the changes will take effect immediately. Any users added to the PowerUsers keystone role will receive these privileges.

For more information on the policy.json syntax options available, see the Policy syntax section below.

5.1.2. Review role assignment
リンクのコピー

  1. You can generate a report of the role assignments: 

    $ openstack role assignment list --names
+---------------+--------------------+-------+----------------------+--------+-----------+
| Role          | User               | Group | Project              | Domain | Inherited |
+---------------+--------------------+-------+----------------------+--------+-----------+
| admin         | glance@Default     |       | services@Default     |        | False     |
| admin         | ceilometer@Default |       | services@Default     |        | False     |
| ResellerAdmin | ceilometer@Default |       | services@Default     |        | False     |
| PowerUsers    | demo-user@Default  |       | demo-project@Default |        | False     |
| admin         | swift@Default      |       | services@Default     |        | False     |
| admin         | aodh@Default       |       | services@Default     |        | False     |
| admin         | neutron@Default    |       | services@Default     |        | False     |
| admin         | nova@Default       |       | services@Default     |        | False     |
| _member_      | demo@Default       |       | demo@Default         |        | False     |
| admin         | cinder@Default     |       | services@Default     |        | False     |
| admin         | admin@Default      |       | admin@Default        |        | False     |
| admin         | gnocchi@Default    |       | services@Default     |        | False     |
+---------------+--------------------+-------+----------------------+--------+-----------+
    Copy to Clipboard Toggle word wrap

  2. You can also view the role assignment for a specific user: 

    $ openstack role assignment list --user demo-user --project demo-project --names
+-------------+----------------+-------+----------------------+--------+-----------+
| Role        | User           | Group | Project              | Domain | Inherited |
+-------------+----------------+-------+----------------------+--------+-----------+
| PowerUsers  | demo-user@Default |       | demo-project@Default |        | False  |
+-------------+----------------+-------+----------------------+--------+-----------+
    Copy to Clipboard Toggle word wrap

5.1.3. Policy syntax
リンクのコピー

Policy.json files support certain operators that allow you to control the target scope of these settings. For example, this keystone setting holds that only admin users are allowed to create users: 

"identity:create_user": "rule:admin_required"
Copy to Clipboard Toggle word wrap

The section to the left of the : character describes the privilege, and the section on the right governs who is allowed to use the privilege. You can also use operators on the right side to further control the scope:

  • ! - No user (including admin) may perform this action.
  • @ and "" - Any user may perform this action.
  • not, and, or - Standard operator functions are available.
  • rule:admin_required or role:admin or rule:owner - Certain predefined rules are available that allow you to match a privilege to type of user.

For example, this setting would mean that no users are allowed to create new users: 

"identity:create_user": "!"
Copy to Clipboard Toggle word wrap
Note

You should test your policy changes before deployment. This will help you determine if they are working as expected.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る