Role¶

A Role determines which API operations a User is permitted to perform. Roles are a licensed feature requiring the rbac license entitlement; without it, roles can only be listed and retrieved.

Each Role contains a list of Claims, where every Claim is a triple of Scope, Action, and Specific. The Scope identifies the object type (for example machines), Action identifies the operation (for example get, list, update, delete), and Specific identifies the target object key. Any of these fields may be set to * as a wildcard that matches everything in that position. At compile time DRP expands and optimizes the claim list so that authorization checks are fast map lookups rather than linear scans.

Roles are partially ordered by the access they grant. Role a is said to contain Role b if every Claim in b can be satisfied by a Claim in a. This ordering allows DRP to reason about relative privilege levels.

DRP ships two built-in roles: superuser (which carries the all-matching */*/* claim and is assigned to the default rocketskates user) and discovery (a minimal role used by the machine discovery process). Custom roles can be created to grant fine-grained access.

Roles are assigned to Users via the User's Roles list, referenced by Tenants for multi-tenant visibility control, and can be automatically granted through IdentityProvider group mapping when SSO is configured.

Claim¶

Claims grant the ability to perform specific actions against specific objects.

Fields¶

Field	Definition
Claims	Claims that the role support.
Claims/Action	Action is the action taken in the space. e.g. get, list Can be comma separated list or *
Claims/Scope	Scope is the object space. e.g. machines Can be comma separated list or *
Claims/Specific	Specific is the id of the object in the object space. e.g. machine uuid Can be comma separated list or *
Description	Description is a string for providing a simple description
Documentation	Documentation is a string for providing additional in depth information.
Meta	Meta contains the meta data of the object. The type of this field is a key / value map/dictionary. The key type is string. The value type is also string. The general content of the field is undefined and can be an arbritary store. There are some common known keys: color - The color the UX uses when displaying icon - The icon the UX uses when displaying * title - The UX uses this for additional display information. Often the source of the object. Specific Object types use additional meta data fields. These are described at: https://docs.rackn.io/stable/redirect/?ref=rs_object_metadata
Name	Name is the name of the user required: true

Actions¶

Two actions have specialized semantics.

Action	Description
`action`	By itself, `action` gives permission for all valid plugin-provided actions.
`action:<actionName>`	This gives permission for the specific action name. If you want to give access to more than one plugin-provided action, you can specify multiple instances in the comma-separated list.
`update`	By itself, `update` gives permission to update any field (including params, if the final object has them).
`update:<field>`	The field part after the colon must be a valid RFC6901 JSON pointer to the field you want to allow to be updated. This will allow updated to that field and any subfields it might have. This level of access control works on the JSON representation of the object.

Claims are partially ordered by the access they grant, with the superuser claim {Scope:"*" Action:"*" Specific:"*"} granting access to everything and the empty claim {Scope:"" Action:"" Specific:""} granting access to nothing. If you have two claims a and b, claim a is said to contain claim b if a is capable of satisfying every authentication request b is.