This section explains extended granular Role Based Access Control (RBAC) feature.
The terms labels and markers are used interchangeably throughout the section.
Multiple values (value 1, value 2, value 3…), mapped to a single key for an object.
Example:
User 1 has to transfer a pre-prod application to prod, for which User 2 has access.
The object has label “app”:[“pre-prod”].
User 1 has access to “app”:”pre-prod”.
User 1 needs to transfer this object to “prod“.
In this case, the object has to be configured with “key” : “list of labels” for transferring the application.
Any user who has access to the object with labels configured in the role, can use additional labels which the user does not have access to.
Here, an additional label has to be applied for the object.
“app“: [“pre-prod”, “prod”] After the transfer, the new app owner (User 2) can remove “app“: “pre-prod“ from the object to discontinue access to User 1.
A flag allow_unlabelled_ access to enable read access to unlabelled objects alongside labels objects, configured with role filters for a user.
Example:
A user with labels in a role needs to access certain standard profiles, which have no labels.
A new object,
LabelGroup
is introduced to track the labels allowed or suggested for a given tenant. For each tenant, there can be associated label groups. At the tenant level, the labels can either be enforced or deprecated.