Skip to main content
Version: 2.0.0

Components

What makes up an RBAC Policy?

An RBAC Policy is the simplest policy that we can define. It's made up of roles, resources and actions.

The basic idea of RBAC is that any role can have the permissions to perform an action on any resource.

Keyword Definitions

Role (Top Level in the UI) - the action and responsibilities that a particular person has, Top level represents the fact that Roles have higher priority in policy evaluation than Instance-level Roles.
Resource - the target object we want to authorize access too.
Action - the process of performing a certain task on a resource.

Simple Example

One role-based access control example is a set of permissions that allow users to read, edit, or delete articles in a writing application. There are two roles, a Writer and a Reader, and their respective permission levels are presented in this truth table. Using this table, you can assign permissions to each user.

Permission/RoleWriterReader
EditYesNo
DeleteYesNo
ReadYesYes
tip

When creating an RBAC policy within the UI, every resource and action will get inherited by any other role (Top Level in the UI) you decide to add.

Below is an example of a two roles; an Admin and a Friend - both with different permissions to view the details within the card resource.

RBAC Example

Let's try an example!