LogoLogo
5.0.X
5.0.X
  • About Trilio for Kubernetes
    • Welcome to Trilio For Kubernetes
    • Version 5.0.X Release Highlights
    • Compatibility Matrix
    • Marketplace Support
    • Features
    • Use Cases
  • Getting Started
    • Getting Started with Trilio on Red Hat OpenShift (OCP)
    • Getting Started with Trilio for Upstream Kubernetes (K8S)
    • Getting Started with Trilio for AWS Elastic Kubernetes Service (EKS)
    • Getting Started with Trilio on Google Kubernetes Engine (GKE)
    • Getting Started with Trilio on VMware Tanzu Kubernetes Grid (TKG)
    • More Trilio Supported Kubernetes Distributions
      • General Installation Prerequisites
      • Rancher Deployments
      • Azure Cloud AKS
      • Digital Ocean Cloud
      • Mirantis Kubernetes Engine
      • IBM Cloud
    • Licensing
    • Using Trilio
      • Overview
      • Post-Install Configuration
      • Management Console
        • About the UI
        • Navigating the UI
          • UI Login
          • Cluster Management (Home)
          • Backup & Recovery
            • Namespaces
              • Namespaces - Actions
              • Namespaces - Bulk Actions
            • Applications
              • Applications - Actions
              • Applications - Bulk Actions
            • Virtual Machines
              • Virtual Machine -Actions
              • Virtual Machine - Bulk Actions
            • Backup Plans
              • Create Backup Plans
              • Backup Plans - Actions
            • Targets
              • Create New Target
              • Targets - Actions
            • Hooks
              • Create Hook
              • Hooks - Actions
            • Policies
              • Create Policies
              • Policies - Actions
          • Monitoring
          • Guided Tours
        • UI How-to Guides
          • Multi-Cluster Management
          • Creating Backups
            • Pause Schedule Backups and Snapshots
            • Cancel InProgress Backups
            • Cleanup Failed Backups
          • Restoring Backups & Snapshots
            • Cross-Cluster Restores
            • Namespace & application scoped
            • Cluster scoped
          • Disaster Recovery Plan
          • Continuous Restore
      • Command-Line Interface
        • YAML Examples
        • Trilio Helm Operator Values
    • Upgrade
    • Air-Gapped Installations
    • Uninstall
  • Reference Guides
    • T4K Pod/Job Capabilities
      • Resource Quotas
    • Trilio Operator API Specifications
    • Custom Resource Definition - Application
  • Advanced Configuration
    • AWS S3 Target Permissions
    • Management Console
      • KubeConfig Authenticaton
      • Authentication Methods Via Dex
      • UI Authentication
      • RBAC Authentication
      • Configuring the UI
    • Resource Request Requirements
      • Fine Tuning Resource Requests and Limits
    • Observability
      • Observability of Trilio with Prometheus and Grafana
      • Exported Prometheus Metrics
      • Observability of Trilio with Openshift Monitoring
      • T4K Integration with Observability Stack
    • Modifying Default T4K Configuration
  • T4K Concepts
    • Supported Application Types
    • Support for Helm Releases
    • Support for OpenShift Operators
    • T4K Components
    • Backup and Restore Details
      • Immutable Backups
      • Application Centric Backups
    • Retention Process
      • Retention Use Case
    • Continuous Restore
      • Architecture and Concepts
  • Performance
    • S3 as Backup Target
      • T4K S3 Fuse Plugin performance
    • Measuring Backup Performance
  • Ecosystem
    • T4K Integration with Slack using BotKube
    • Monitoring T4K Logs using ELK Stack
    • Rancher Navigation Links for Trilio Management Console
    • Optimize T4K Backups with StormForge
    • T4K GitHub Runner
    • AWS RDS snapshots using T4K hooks
    • Deploying Trilio For Kubernetes with Openshift ACM Policies
  • Krew Plugins
    • T4K QuickStart Plugin
    • Trilio for Kubernetes Preflight Checks Plugin
    • T4K Log Collector Plugin
    • T4K Cleanup Plugin
  • Support
    • Troubleshooting Guide
    • Known Issues and Workarounds
    • Contacting Support
  • Appendix
    • Ignored Resources
    • OpenSource Software Disclosure
    • CSI Drivers
      • Installing VolumeSnapshot CRDs
      • Install AWS EBS CSI Driver
    • T4K Product Quickview
    • OpenShift OperatorHub Custom CatalogSource
      • Custom CatalogSource in a restricted environment
    • Configure OVH Object Storage as a Target
    • Connect T4K UI hosted with HTTPS to another cluster hosted with HTTP or vice versa
    • Fetch DigitalOcean Kubernetes Cluster kubeconfig for T4K UI Authentication
    • Force Update T4K Operator in Rancher Marketplace
    • Backup and Restore Virtual Machines running on OpenShift
    • T4K For Volumes with Generic Storage
    • T4K Best Practices
Powered by GitBook
On this page
  • Background
  • Default Cluster Roles
  • triliovault-admin
  • triliovault-reader
  • triliovault-admin for specific namespace
  • triliovault-reader for specific namespace
  • triliovault-login-only
  • Custom role
  • Application view permission
  • Cluster wide permissions
  • Upstream Namespaced T4K

Was this helpful?

  1. Advanced Configuration
  2. Management Console

RBAC Authentication

Using Role Based Access Control (RBAC) to control T4K UI access

PreviousUI AuthenticationNextConfiguring the UI

Last updated 4 months ago

Was this helpful?

Before proceeding, make sure to read the Kubernetes published documentation entitled .

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

Every user must have secret create permission in T4K installation namespace in order to login to the T4K UI (web portal)

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 <binding-name> --clusterrole=triliovault-admin --user=<user-name>
kubectl create clusterrolebinding <binding-name> --clusterrole=triliovault-admin --group=<user-name>
kubectl create clusterrolebinding <binding-name> --clusterrole=triliovault-admin --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

Created Cluster Role Bindings

The above command creates a cluster role binding as below:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: triliovault-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: <user-name>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: triliovault-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: <group-name>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: triliovault-admin
subjects:
  - kind: ServiceAccount
    name: <serviceaccount_name>
    namespace: <serviceaccount_namespace>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: triliovault-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: <user-name>
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: <group-name>
- kind: ServiceAccount
  name: <serviceaccount_name>
  namespace: <serviceaccount_namespace>

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 <binding-name> --clusterrole=triliovault-reader --user=<user-name>
kubectl create clusterrolebinding <binding-name> --clusterrole=triliovault-reader --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

This will create clusterrolebindings similar to Created Cluster Role Bindings.

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 <binding-name> --clusterrole=triliovault-admin --user=<user-name> -n namespace-a
kubectl create rolebinding <binding-name> --clusterrole=triliovault-admin --user=<user-name> -n namespace-b
# similarly for service account
kubectl create rolebinding <binding-name> --clusterrole=triliovault-admin --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name> -n namespace-a
kubectl create rolebinding <binding-name> --clusterrole=triliovault-admin --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name> -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 <binding-name> --clusterrole=triliovault-reader --user=<user-name> -n namespace-a
kubectl create rolebinding <binding-name> --clusterrole=triliovault-reader --user=<user-name> -n namespace-b
# similarly for service account
kubectl create rolebinding <binding-name> --clusterrole=triliovault-reader --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name> -n namespace-a
kubectl create rolebinding <binding-name> --clusterrole=triliovault-reader --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name> -n namespace-b

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.

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 <binding-name> --role=triliovault-login-only --user=<user-name>
kubectl create rolebinding <binding-name> --role=triliovault-login-only --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

This will create clusterrolebindings similar to Created Cluster Role Bindings.

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 <binding-name> --clusterrole=triliovault-target-policy-reader --user=<user-name>
# or for service account
kubectl create clusterrolebinding <binding-name> --clusterrole=triliovault-target-policy-reader --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

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 <binding-name> --clusterrole=backups-restore-hooks-creator --user=<user-name> -n namespace-a
# or for service account
kubectl create rolebinding <binding-name> --clusterrole=backups-restore-hooks-creator --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name> -n namespace-a

You may also add rules for T4K resources in your existing cluster role or role directly, to avoid creating clusterrolebinding/rolebindings.

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=<username>

Using RBAC Authorization