# RBAC Authentication {% hint style="info" %} Before proceeding, make sure to read the Kubernetes published documentation entitled [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). {% endhint %} ## Background T4K uses RBAC provided by kubernetes to control access to T4K resources. T4K pre-installs some standard roles, but the administrator of a cluster 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 fulfil 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 T4K). 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 | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **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. | ## Default Cluster Roles {% hint style="info" %} Every user must have secret create permission in T4K installation namespace in order to login to the T4K UI (web portal) {% endhint %} ### triliovault-admin This role provides full access to all T4K resources across all namespaces. Below is the definition of the **triliovault-admin** cluster role: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: triliovault-admin rules: - apiGroups: - triliovault.trilio.io/v1 resources: - '*' verbs: - '*' - apiGroups: - "" resources: - secrets verbs: - create ``` To make users a **tvk-admin** in group or service\_account, *clusterrolebinding* must be created using the command: ``` kubectl create clusterrolebinding --clusterrole=triliovault-admin --user= kubectl create clusterrolebinding --clusterrole=triliovault-admin --group= kubectl create clusterrolebinding --clusterrole=triliovault-admin --serviceaccount=: ``` #### Created Cluster Role Bindings The above command creates a cluster role binding as below: {% tabs %} {% tab title="User" %} ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: triliovault-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: ``` {% endtab %} {% tab title="Group" %} ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: triliovault-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: ``` {% endtab %} {% tab title="Service Account" %} ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: triliovault-admin subjects: - kind: ServiceAccount name: namespace: ``` {% endtab %} {% tab title="Combination" %} ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: triliovault-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: - apiGroup: rbac.authorization.k8s.io kind: Group name: - kind: ServiceAccount name: namespace: ``` {% endtab %} {% endtabs %} ### triliovault-reader This role provides read-only access to all T4K resources across all namespaces. Below is the definition of the **triliovault-reader** cluster role: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: triliovault-reader rules: - apiGroups: - triliovault.trilio.io/v1 resources: - '*' verbs: - get - watch - list - apiGroups: - "" resources: - secrets verbs: - create ``` To make *users* or *service account* a **triliovault-reader**, clusterrolebinding must be created using the command: ``` kubectl create clusterrolebinding --clusterrole=triliovault-reader --user= kubectl create clusterrolebinding --clusterrole=triliovault-reader --serviceaccount=: ``` This will create clusterrolebindings similar to [#created-cluster-role-bindings](#created-cluster-role-bindings "mention"). ### triliovault-admin for specific namespace This role provides full access to all T4K resources for specific namespaces only. It uses the definition of the **triliovault-admin** cluster role: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: triliovault-admin rules: - apiGroups: - triliovault.trilio.io/v1 resources: - '*' verbs: - '*' - apiGroups: - "" resources: - secrets verbs: - create ``` 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: ``` kubectl create rolebinding --clusterrole=triliovault-admin --user= -n namespace-a kubectl create rolebinding --clusterrole=triliovault-admin --user= -n namespace-b # similarly for service account kubectl create rolebinding --clusterrole=triliovault-admin --serviceaccount=: -n namespace-a kubectl create rolebinding --clusterrole=triliovault-admin --serviceaccount=: -n namespace-b ``` ### triliovault-reader for specific namespace This role provides *read-only* access to all T4K resources for specific namespaces only. It uses the definition of the **triliovault-reader** cluster role: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: triliovault-reader rules: - apiGroups: - triliovault.trilio.io/v1 resources: - '*' verbs: - get - watch - list - apiGroups: - "" resources: - secrets verbs: - create ``` 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: ``` kubectl create rolebinding --clusterrole=triliovault-reader --user= -n namespace-a kubectl create rolebinding --clusterrole=triliovault-reader --user= -n namespace-b # similarly for service account kubectl create rolebinding --clusterrole=triliovault-reader --serviceaccount=: -n namespace-a kubectl create rolebinding --clusterrole=triliovault-reader --serviceaccount=: -n namespace-b ``` {% hint style="info" %} 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. {% endhint %} ### triliovault-login-only This role provides only login access to all T4K resources. The user may explore the T4K UI, but cannot take any actions. It uses the definition of the **triliovault-login-only** role: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: triliovault-login-only rules: - apiGroups: - "" resources: - secrets verbs: - create ``` To provide login access only for *users* or *service account,* rolebinding (in the T4K installation namespace) must be created using the command: ``` kubectl create rolebinding --role=triliovault-login-only --user= kubectl create rolebinding --role=triliovault-login-only --serviceaccount=: ``` This will create clusterrolebindings similar to [#created-cluster-role-bindings](#created-cluster-role-bindings "mention"). ### Custom role 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: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: triliovault-target-policy-reader rules: - apiGroups: - triliovault.trilio.io/v1 resources: - targets - policies verbs: - get - list - watch - apiGroups: - "" resources: - secrets verbs: - create ``` For the same example, now create cluster role binding for the user or service account, using the following commands: ``` kubectl create clusterrolebinding --clusterrole=triliovault-target-policy-reader --user= # or for service account kubectl create clusterrolebinding --clusterrole=triliovault-target-policy-reader --serviceaccount=: ``` Now, configure the cluster role for 'write' access to backups/restores/hooks. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backups-restore-hooks-creator rules: - apiGroups: - triliovault.trilio.io/v1 resources: - backups - restores - hooks verbs: - create ``` Finally, create role binding for the user or service account to give clusterscope 'create' access ``` kubectl create rolebinding --clusterrole=backups-restore-hooks-creator --user= -n namespace-a # or for service account kubectl create rolebinding --clusterrole=backups-restore-hooks-creator --serviceaccount=: -n namespace-a ``` {% hint style="info" %} You may also add rules for T4K resources in your existing cluster role or role directly, to avoid creating clusterrolebinding/rolebindings. {% endhint %} ### Application view permission 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. ### Cluster wide permissions To view Cluster scope resources like ClusterBackupPlan, ClusterBackup, ClusterRestore, ContinuousRestorePlan, ConsistentSet only cluster-wide permissions are needed, namespace level permissions won't work ## Upstream Namespaced T4K In the case of the upstream Namespace T4K installation, instead of ClusterRole/s, Role/s will be created in the install-namespace. To create rolebindings in the install-namespace, Role/s must be referred. For example, to assign *admin* permission to a user, use this command:\ \ `kubectl create rolebinding --role=triliovault-admin --user=`