RBAC Terms and Concepts
Before using the RBAC API, you should know the following RBAC terms.
Role-Based Access Control (RBAC)
RBAC has two main concepts: users and permissions.
User
A user is a PCE account that provides login or API access to the PCE. The PCE can manage a user locally or externally through an IdP.
Permission
A permission represents a combination of a user's account, an RBAC role, and an optional scope. You can grant multiple permissions to a user, depending on your requirements. A permission is a three-tuple consisting of a role, a scope, and an authorization security principal:
Role
User personas are associated with allowed operations, such as creating new labels or provisioning policy changes. Roles can be one of two general types: unscoped and scoped.
Unscoped roles (or roles with “global scopes”) do not restrict the types of resources a user can operate. This means that the role is not affected by any label scopes.
Scoped roles use one or more unique application, environment, and location labels (each with a label HREF, key, and value), to restrict user or group permissions to only those objects that share the same labels. Specifically, scoped roles allow certain users to create and provision rules and rulesets.
Scope
A set of three labels (one of each type for Application, Environment, and Location) that restricts operations to those workloads sharing the same labels as the scope label set.
A set of three labels (one of each type for Application, Environment, and Location) that restricts operations to those workloads sharing the same labels as the scope label set.
A scope contains zero or more applications, environments, and location labels. Each label in the scope is identified by its HREF. A scope can also contain zero or more label groups.
If one of the label types is not specified, all instances of that type are permitted. For example, all applications are within the scope if application labels are omitted, but environment and location labels are present.
Authorization Security Principal
The binding connects a user account with its permissions (a role, and, depending on the role, scopes).
Note
If you use an external identity provider to manage user access to the PCE, ensure that your identity provider is configured and that external users have been added to the PCE before you use this API to assign user permissions.
Grant Permissions Workflow
Granting user permissions with the REST API follows this general workflow:
Create a local user (optional)
This step creates a new local PCE user with no permissions and sends an email invitation to the user's email address. (If you use an external identity source to manage user access to the PCE, skip this step.)
Create an authorization security principal
An authorization security principal is binding between a user or group, an RBAC role, and optional scopes.
Grant permissions by assigning a role and scopes to the authorization security principal
Once a user account has been associated with an authorization security principal, you can assign it an RBAC role and add custom scopes if the user role requires them.