Entitlements System Policy Model
The Styra DAS Entitlements System type gives you pre-built policy snippets to implement a variety of Policy Models, including:
- Role-based access control (RBAC)
- Attribute-based access control (ABAC)
- Time-based access control
- Location-based access control
- Custom policy models using Rego
To implement RBAC, you must map subjects to roles through role bindings.
A role defines a set of permissions over resources, and a role binding attaches a role to a set of subjects. Users and service accounts that belong to groups inherit the permissions of those groups. Group membership may be specified explicitly or by attribute matching. The following figure shows the RBAC model.
Roles define permissions over resources, and a permission is the set of actions permissible over a set of resources.
For example, a role single role with ID
id could be defined as:
// allow grants access to resources selected by include and not selected by the exclude selectors
"actions": ["action-id", "action.*"],
"resources": ["glob/*/selector", "resource-id"]
"resources": ["*", "resource-id"]
// deny removes access to resources allowed by any roles
When defined this way, roles provide a convenient way to express allow or deny lists over action/resource combinations. By default, roles do not do grant any permissions on their own. They need a role binding to be associated with subjects.
A Role binding attaches a role to a set of subjects. Role bindings can be expressed by subject IDs or subject attributes, or both.
For example, the following associates the role with ID
role-id with all subjects who have the attribute
attribute-id with value
value. It also associates
role-id with the subjects
"ids": ["user-id", "group-id"]
When subjects are selected by both attribute and ID, the union of subjects matching those selectors are bound to the given role.