By Trilio Content Team | August 17, 2021
How-To: Trilio for Kubernetes — Management Console Permissions
Trilio for Kubernetes is an application-centric data protection platform that provides backup and migration capabilities to empower organizations to manage Kubernetes backups with flexibility and industry-standard compatibility. As more and more organizations turn to Kubernetes, it’s important for IT Operations and DevOps teams to treat data protection of applications as a day-one priority in order to prevent any loss of data (including metadata or Kubernetes objects associated with these applications).
The following “How-To” article provides expert tips for Trilio users. It outlines how to configure the Trilio Management Console RBAC (Role-Based Access Control) to mirror that of an existing Oauth identity provider and the benefits of this configuration.
Before we get started, here are some of the features of the Trilio Management Console:
- Discovery of Kubernetes applications
- Intuitive management of Backup and Restore Plans in real-time across clouds
- Simple workflows for managing application-consistent backups and restores
- Ability to migrate application data and metadata to other clouds
- Monitoring of overall health with performance metrics
Synopsis
Kubernetes is especially popular with DevOps teams due to its multi-tenancy, resiliency, scalability, and efficient deployment methodology. Today we’ll focus on multi-tenancy, which allows you to give specific permissions to users, such as access to certain namespaces and resources. Trilio uses the same multi-tenant structure by natively integrating with a key pillar of Kubernetes — Role-Based Access Control (RBAC).
Bringing DevOps and IT Ops together — with both teams working on the same tools and infrastructure — is an important part of Kubernetes. RBAC is a key pillar for multi-team collaboration on Kubernetes. Trilio integrates natively into Kubernetes-based roles and permissions, removing the need for a separate RBAC policy framework. Each user can perform Trilio operations based on their specific RBAC within the Kubernetes system.
Trilio provides native Kubernetes backup and recovery of all application metadata, data, and Kubernetes objects. Trilio is built from the ground up to adhere to the core principles of Kubernetes. In this blog, we will demonstrate how to integrate Trilio with Kubernetes RBAC to leverage existing permissions on your cluster.
How It Works
When you install Trilio, a service account is created with permissions to access Trilio and the Management Console. However, you may want to configure an OAuth identity provider, such as GitHub, on your cluster to validate usernames and passwords. If that is the case, some extra steps are required. For instance, you will need to set up a ClusterRole and a ClusterRoleBinding to set up permission for the ‘system:authenticated: oauth group. This blog details the process for setting up that configuration.
Scenario
As the person responsible for storage resources and management within the organization, the cluster admin (IT Ops) needs to be the sole creator of backup targets and have control over backup and restore operations. The developer engineer (DevOps) wants to consume that backup target to store their backups. Here are the permissions that the cluster admin would set for themself and for a lead software developer. With these permissions in place, they won’t be able to create the target but will be able to choose where to execute their backups from among the available targets created by the cluster admin.
Cluster Permissions
To access the Management Console and these features, you will need to create a ClusterRole and a ClusterRoleBinding.
The Trilio for Kubernetes Management Console leverages existing cluster permissions to determine who has access. At a minimum, users logging in to the Console need to have read permissions for the Trilio group resource. The following ClusterRole shows the minimum level of permissions required to access the Trilio Management Console.
Example 1: apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: svcs-role
rules:
- apiGroups: ["triliovault.trilio.io"]
resources: ["*"]
verbs: ["get", "list"]
- apiGroups: ["triliovault.trilio.io"]
resources: ["policies"]
verbs: ["create"]
You may want to expand these permissions to include some or all of the resources below:
Trilio for Kubernetes provides the following CRDs:
- Target: Designated NFS | S3 location to store backups
- Policy: Backup frequency and backup retention
- Hook: Pre and Post triggers to execute commands inside containers
- BackupPlan: Kubernetes application, target, policy, hook
- Restore: Performs the Trilio restore operation
Verbs give users and groups permission to execute actions associated with a resource.
Verbs:
create
delete
deletecollection
get
list
patch
update
watch
Resources:
backupplans
backups
hook
licenses
policies
restores
targets
A list of resources can be gathered by running the command:
oc get crd | grep -i trilio
Example 2 – The Cluster Admin creates and deletes permissions needed to log into the Trilio Management Console and create targets and licenses.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: svcs-role
rules:
- apiGroups: ["triliovault.trilio.io"]
resources: ["*"]
verbs: ["get", "list"]
- apiGroups: ["triliovault.trilio.io"]
resources: ["policies", "targets", "licenses"]
verbs: ["create", "delete"]
Example 3 – Lead Software Developer:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: svcs-role
rules:
- apiGroups: ["triliovault.trilio.io"]
resources: ["*"]
verbs: ["get", "list"]
- apiGroups: ["triliovault.trilio.io"]
resources: ["policies", "backups", "restores", "backupplans", "hooks", ]
verbs: ["create", "delete"]
Example 4 – Full Permissions:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: svcs-role
rules:
- apiGroups: ["triliovault.trilio.io"]
resources: ["*"]
verbs: ["*"]
Steps to create your ClusterRole in the Red Hat OpenShift Container Platform (OCP) UI
Navigate to User Management —> Roles
Create a new ClusterRole for all namespaces
Create a cluster-wide RoleBinding for your newly created ClusterRole
This cluster uses an Oauth provider, so we used the system:authenticated:oauth group. If you are using a different provider, find the appropriate group based on your provider.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: svcs-binding
subjects:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: 'system:authenticated:oauth'
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: svcs-role
Log into OCP with a user account (non-admin)
When logging in with the CLI for the first time, OpenShift creates a ~/.kube/config file if one does not already exist.
Access kubeconfig file with the command:
cat ~/.kube/config
Copy the kubeconfig file contents into the file on your local machine.
With your new ClusterRole and RoleBindings in place, that kubeconfig file should now have the correct permissions to be used with the Trilio Management Console.
Conclusion
Trilio for Kubernetes makes sense for a multi-tenant environment with distinct IT Ops and Dev teams with different roles, as is commonly seen in today’s IT organizations. This article outlined how to configure Trilio Management Console RBAC to align with existing roles and permissions in Kubernetes RBAC.
For more information on Trilio for Kubernetes request a demo or check out Trilio’s documentation.
