Chapter 10. Improving user access security
This feature is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.
You can enable secure role-based access control (SRBAC) in Red Hat OpenStack Platform 17. The SRBAC model has three personas, based on three roles existing within the project scope.
10.1. SRBAC personas
Personas are a combination of roles and the scope to which they belong. When you deploy Red Hat OpenStack Platform 17, you can assign any of the personas from the project scope.
10.1.1. Red Hat OpenStack Platform SRBAC roles
Currently, three different roles are available within the project scope.
adminrole includes all create, read, update, or delete operations on a resource or API.
memberrole is allowed to create, read, update, and delete resources that are owned by the scope in which they are a member.
readerrole is for read-only operations, regardless of the scope it is applied to. This role can view resources across the entirety of the scope to which it is applied.
10.1.2. Red Hat OpenStack Platform SRBAC scope
The scope is the context in which operations are performed. Only the
project scope is available in Red Hat OpenStack Platform 17. The
project scope is a contained subset of APIs for isolated self-service resources within OpenStack.
10.1.3. Red Hat OpenStack Platform SRBAC personas
- Project admin
Because the project admin persona is the only administrative persona available, Red Hat OpenStack Platform 17 includes modified policies that grant the project admin persona the highest level of authorization. This persona includes create, read, update and delete operations on resources across projects, which includes adding and removing users and other projects.Note
This persona is expected to change in scope with future development. This role implies all permissions granted to project members and project readers.
- Project member
- The project member persona is for users who are granted permission to consume resources within the project scope. This persona can create, list, update, and delete resources within the project to which they are assigned. This persona implies all permissions granted to project readers.
- Project reader
- The project reader persona is for users who are granted permission to view non-sensitive resources in the project. On projects, assign the reader role to end users who need to inspect or view resources, or to auditors, who only need to view project-specific resources within a single project for the purposes of an audit The project-reader persona will not address all auditing use cases.
Additional personas based on the
domain scopes are in development and are not available for use.
10.2. Activating secure role-based access control
When you activate secure role-based Authentication, you are activating a new set of policy files that define the scope of permissions assigned to users in your Red Hat OpenStack Platform environment.
- You have an installed Red Hat OpenStack Platform director environment.
enable-secure-rbac.yamlenvironment file in the deployment script when deploying Red Hat OpenStack Platform:
openstack overcloud deploy --templates … -e /usr/share/openstack-tripleo-heat-templates/environments/enable-secure-rbac.yaml
10.3. Assigning roles in an SRBAC environment
With SRBAC on Red Hat OpenStack Platform, you can assign users to the role of
- You have deployed Red Hat OpenStack Platform with secure role based authentication (SRBAC).
openstack role addcommand using the following syntax:
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> admin
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> member
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> reader
<user>with an existing user to apply the role.
<domain>with the domain to which the role applies.
<project>with the project for which the user is being granted the role.
<project-domain>with the domain that the project is in.