Object Model for Roles
The Entitlements System has pre-built snippets that can be used to enforce role-based access control without authoring in Rego. These snippets depend on the object model to define role and role bindings.
A role defines a set of permissions over resources. A permission is the set of actions permissible over a set of resources.
For example, a single role with an identifier id
is defined as:
{
"id": {
// allow grants access to resources selected by include and not selected by the exclude selectors
"allow": {
"include": [{
"actions": ["action-id"],
"resources": ["glob/*/selector", "resource-id"]
}],
"exclude": [{
"actions": ["action-id"],
"resources": ["*", "resource-id"]
}]
},
// deny removes access to resources allowed by any roles
"deny": {
"include": [{
"actions": ["action-id"],
"resources": ["**"]
}],
"exclude": [{
"actions": ["action-id"],
"resources": ["resource-id"]
}]
}
}
}
Using this definition, roles provide a convenient way to express allow or deny lists over action/resource combinations. By default, roles do not grant any permissions. They need a role binding to be associated with subjects.
Role binding attaches a role to a set of subjects. Role bindings can be expressed by subject IDs, 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 user-id
and group-id
.
{
"role-id": {
"subjects": {
"attributes": {
"attribute-id": "value",
},
"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.