How to Configure K10 with RBAC for Multi-Tenant Environments
A common requirement that shows up during conversations with customers is that they would like K10, Kasten’s data management platform, to provide multi-tenancy. At Kasten, we have achieved this by integrating natively with Kubernetes Role Based Access Control (RBAC).
This article will cover the following topics:
Enumerate the roles that can be associated with K10
Examples of operations associated with each role
How Kubernetes RBAC is used to implement these roles and associate them with users or groups
Screenshots from the product to show the different views seen by users with different roles
Since we leverage Kubernetes’ native RBAC, the users have a lot of flexibility when it comes to defining various types of roles and assign varying levels of permissions to each role.
For the purpose of this article, we will use the table below to define a specific use case where an enterprise would like to have two types of roles with varying levels of access to K10. Note that this is only for illustrative purposes, and does not mean that these are the only types of roles available with K10.
Unrestricted access to all operations and configurations
Typically, a small number of users would like to operate K10 as administrators. The administrators would like to offer another set of users (Basic Users), limited access to K10’s platform. The admins would like to prevent the basic users from operating and viewing admin level tasks such as configurations as an example.
Let's define the requirements for the Admin and Basic users. We can then translate these requirements into Kubernetes objects that will implement these requirements.
These are examples of tasks that can only be done by an admin user:
Admin User Operations
Creation of policies to protect any application in the cluster.
Creation of location profiles that represent a Backup target such as an S3 bucket.
List Actions created by all types of users in any namespace.
These are examples of tasks that can be done by the basic user:
Basic User Operations
List Applications only in namespaces where the basic user has access.
Backup and restore applications only in namespaces where the basic user has access.
Defining a Cluster Role for Admin Users
A Kubernetes Cluster Role contains rules that represent a set of permissions. When K10 is deployed, a Cluster Role named k10-admin is created.
To meet the policy and profile creation requirements enumerated in the previous section for an Admin user, you will see a rule below that says all operations (identified by the “*” for verbs) are permitted on all resources (identified by the “*” for resources) in the api group config.kio.kasten.io. Since K10’s policies and profiles are resources under this api group, the Admin users are able to create and view policies and profiles in K10.
To meet the requirement of listing all actions created by any user, there is a rule below that says all operations are permitted on all resources in the api group actions.kio.kasten.io. This is why an Admin user can list any type of Action - Backup/ Restore/Export /Import /Retire actions created by any user in any namespace.
To assign this role to a particular user a Kubernetes Cluster Role Binding is created. Here is an example of a Cluster Role binding to attach a user named firstname.lastname@example.org to the k10-admin Cluster Role:
More often, our customers prefer associating a group to the k10-admin Cluster Role. This allows them to define only one Cluster Role Binding in their cluster for the group instead of creating/deleting Cluster Role Bindings per user. Here is an example of a Cluster Role Binding that binds a group named k10:admins to the k10-admin Cluster Role.
Let’s assume that K10 has been deployed with OIDC (OpenID Connect) based authentication where the provider is Okta. To enable admin level access to an Okta user, all they have to do is include the user in the group named k10:admins via the Okta dashboard.
When the user logs into K10 via the dashboard, they will be redirected to Okta. After successful authentication with Okta, the user will be redirected back to K10’s dashboard. K10 receives a token from Okta for this user. The token will contain information about the groups that the user belongs to.
K10 uses the information in the token to run a Kubernetes Subject Access Review to evaluate the permissions granted to this user in the Kubernetes cluster. Since the Cluster Role Binding shown above is present, and since the group in the user’s token matches with the group in the “Subject” of the binding, the user is granted admin level access to K10.
Screenshots for the Admin User
The user named email@example.com is redirected to the Okta login screen while accessing the K10 dashboard.
After successfully being authenticated by Okta, the user is redirected to K10’s dashboard.
The user is able to view all the applications in this cluster.
The user is also able to view actions corresponding to multiple namespaces in the cluster.
The admin user is able to view policies and profiles.
Defining a Cluster Role for the Basic Users
When K10 is deployed a Cluster Role named k10-basic is created.
To meet the requirement of listing applications only in namespaces where the basic user has access, you will find a rule that says all operations for the resources named restorepoints and applications within the api group apps.kio.kasten.io are allowed.
To meet the requirement of allowing a basic user to backup or restore only the applications that they have access to , you will find a rule below that says all operations on the backupactions and restoreactions resources are permitted within the api group actions.kio.kasten.io.
You will also notice that the Basic role does not have any rules associated with profiles and policies. This helps meet the requirement of the administrators to prevent basic users from modifying or viewing admin level tasks.
To assign the Basic role to a specific user named firstname.lastname@example.org, a Role Binding is created in a specific namespace.
Notice that we are not creating a Cluster Role Binding because we want to restrict this Cluster Role only to a namespace where the basic user is allowed to operate. In this case the namespace is k10-basic-user-ns-1
The user named email@example.com is redirected to the Okta login page while accessing K10’s dashboard.
Notice that this Basic user’s view of the dashboard is different compared to the Admin user. This user is able to see only 3 of the 8 applications in this cluster. This is because the k10-basic Cluster Role is bound to the user named firstname.lastname@example.org only in these three namespaces using Role Bindings.
This user is able to see only the action from a namespace where the user has access.
This user is not able to view policies and profiles.
Defining a Cluster Role for Config Users
Here we want to show another type of user named a Config User who can only view the configuration in K10 but cannot modify them. This user is also not allowed to view or perform operations on the applications in the cluster such as backup or restore.
The user named email@example.com is redirected to the Okta login page while accessing K10’s dashboard.
This user’s view is different compared to the Admin and Basic users.
The config user cannot view the applications in the cluster.
This user cannot view any actions in this cluster either.
This user is only allowed to view policies and profiles.
At Kasten, we have always focussed on listening to our customers' requirements while building and improving the product. The multi-tenancy that we described through this article is also a direct result of listening to feedback from our users. We have multiple customers who are using this today for their day-to-day cloud-native backup and recovery requirements across multiple Kubernetes clusters that have different types of users.
To learn more about Role Based Access Control for K10, please read our documentation here.
To learn more about how to set up OIDC based authentication (mentioned in this article) with K10, please read this blog . We have multiple modes of authentication that are supported with K10 documented here.
We encourage you to give Kasten K10 a try for FREE no sign-up needed, and let us know how we can help. We look forward to hearing from you!
Onkar Bhat is a member of the technical staff at Kasten and has been working on solving problems pertaining to data protection and disaster recovery in cloud native environments. His focus has been in the areas of authentication and authorization for multi-tenant and self-service data protection in Kubernetes. He previously worked as a Technical Lead in the SDN controller team at Big Switch Networks, which was acquired by Arista Networks in 2020. Prior to Big Switch, Onkar worked at NetApp on the SnapMirror team, backup and disaster recovery for on-prem storage, and the Altavault product, a cloud backup appliance. He has also worked on the Catalyst 6K team in the area of deep packet inspection at Cisco Systems. Onkar received his MS from Carnegie Mellon University.
Kasten, Inc. 8800 Lyra Drive, Suite 450 Columbus, Ohio 43240
We value the critical role that the security community plays in helping us protect the confidentiality, integrity, and availability of our software, services, and information. If you have information about security vulnerabilities that affect Kasten software, services, or information, please report it to us via our HackerOne Vulnerability Disclosure Program, or anonymously via this form.