Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

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

  2. Create the custom keystone role: 

    $ openstack role create PowerUsers
+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| domain_id | None                             |
| id        | 7061a395af43455e9057ab631ad49449 |
| name      | PowerUsers                      |
+-----------+----------------------------------+

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

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

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

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

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"

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": "!"
Note

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