RBAC Authentication
Using Role-Based Access Control (RBAC) to control Trilio UI access
Last updated
Using Role-Based Access Control (RBAC) to control Trilio UI access
Last updated
Before proceeding, make sure to read the Kubernetes published documentation entitled Using RBAC Authorization.
Trilio uses RBAC provided by Kubernetes to control access to Trilio resources. Trilio pre-installs some standard roles, but a cluster administrator must create bindings to give the access defined in that standard role to a user, group, or service_account.
Additionally, custom roles may be defined to fulfill more granular access control. For example, you might wish to provide write permission for only Target and Backup resources in a specific namespace, but not for other namespaces. This page explains how you might approach situations like this.
Trilio aims to keep the UI completely stateless, where each Kubernetes user is able to configure their bespoke UI experience based on the specific clusters that they have access to (only clusters installed with Trilio). Since Trilio supports both namespace installation and cluster scope installation, understanding the resulting user experience becomes important. Refer to the following side-by-side scenarios and their results to understand this more.
| Scenario 1 | Scenario 2 | |
|---|---|---|
Every user must have secret create permission in the Trilio installation namespace in order to login to the Trilio UI (web portal)
This role provides full access to all Trilio resources across all namespaces. Below is the definition of the triliovault-admin cluster role:
To make users a tvk-admin in group or service_account, clusterrolebinding must be created using the command:
The above command creates a cluster role binding as below:
This role provides read-only access to all Trilio resources across all namespaces. Below is the definition of the triliovault-reader cluster role:
To make users or service account a triliovault-reader, clusterrolebinding must be created using the command:
This will create clusterrolebindings similar to Created Cluster Role Bindings.
This role provides full access to all Trilio resources for specific namespaces only. It uses the definition of the triliovault-admin cluster role:
However, whilst it uses the above cluster role triliovault-admin, instead of creating clusterRoleBinding, you must create rolebinding in required namespaces. To make users or a service account a triliovault-admin for namespace-a and namespace-b, rolebinding must be created for both the namespaces, as follows:
This role provides read-only access to all Trilio resources for specific namespaces only. It uses the definition of the triliovault-reader cluster role:
However, whilst it uses the above cluster role triliovault-reader, instead of creating clusterRoleBinding, you must create rolebinding in required namespaces. To make users or a service account a triliovault-reader for namespace-a and namespace-b, rolebinding must be created for both the namespaces, as follows:
For specific namespaces, access role can be used instead of cluster role, but the role must be created in each namespace where the rolebinding is to be created.
This role provides only login access to all Trilio resources. The user may explore the Trilio UI, but cannot take any actions. It uses the definition of the triliovault-login-only role:
To provide login access only for users or service account, rolebinding (in the Trilio installation namespace) must be created using the command:
This will create clusterrolebindings similar to Created Cluster Role Bindings.
To provide custom permissions, you must create clusterRoles/roles and create clusterRoleBindings/roleBindings for this respectively.
Example: Let's say that a cluster admin wishes to create a customRole in which targets and policies across the entire cluster may be read. Perhaps the cluster admin wishes that the user can create backups/restores/hooks in namespace 'namespace-a' only. This scenario means that two clusterRoles must be created; one for granting targets/policies 'read' access across the entire cluster and another for granting backups/restores/hooks 'create' access. Also needed, is one clusterRoleBinding for 'read' access and another roleBinding for the 'create' permission for a single namespace
For the above example, the cluster role for the target/policy 'read' access across all namespaces can be configured using the following:
For the same example, now create cluster role binding for the user or service account, using the following commands:
Now, configure the cluster role for 'write' access to backups/restores/hooks.
Finally, create role binding for the user or service account to give clusterscope 'create' access
You may also add rules for Trilio resources in your existing cluster role or role directly, to avoid creating clusterrolebinding/rolebindings.
To view applications such as Helm charts, Labels, or Objects in particular namespaces; the logged-in user/service-account/group that a user belongs to must have a permission to list backupplans in that particular namespace.
To view Cluster scope resources like ClusterBackupPlan, ClusterBackup, ClusterRestore, ContinuousRestorePlan, and ConsistentSet only cluster-wide permissions are needed, namespace level permissions won't work
Installation
Cluster scope level
Namespace level scope within Namespace 1
User 'A' access
Namespace 1, 2 and 3
Namespace 1, 2 and 3
User 'B' access
Namespace 2 and 3
Namespace 2 and 3
RBAC set on the Trilio CRDs
No
No
Scenario result
User A and User B will only see the namespaces that they have access to when they access the UI. Both users will be able to perform Trilio actions without any restrictions.
User A will only see namespace 1 when logged into the UI. Namespace 1 will show as a single namespace cluster within the UI. User B will not see any clusters (or namespaces) in the UI when they log in.