How to Configure K10 with RBAC for Multi-Tenant Environments

10 min readJan 24, 2021

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

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.

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.

Operations

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:

These are examples of tasks that can be done by the basic user:

Implementation

Admin User

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.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2020-10-30T19:20:38Z"
  labels:
    app: k10
    app.kubernetes.io/instance: k10
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: k10
    helm.sh/chart: k10-20201030.47118.8ccf6ef
    heritage: Tiller
    release: k10
  name: k10-admin
  resourceVersion: "1638646"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/k10-admin
  uid: 91575b56-e206-43df-9596-306cc59af8b4
rules:
- apiGroups:
  - config.kio.kasten.io
  - actions.kio.kasten.io
  - apps.kio.kasten.io
  - vault.kio.kasten.io
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - cr.kanister.io
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - create
  - get
  - list

Binding Users to the Admin Role

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 production+admin@kasten.io to the k10-admin Cluster Role:

# kubectl get clusterrolebinding k10-admin-user-rolebinding -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2020-10-26T21:19:15Z"
  name: k10-admin-user-rolebinding
  resourceVersion: "2125477"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/k10-admin-user-rolebinding
  uid: 40bf850f-3b7a-41f3-8757-b8a073d202d4
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: production+admin@kasten.io
  namespace: kasten-io

Binding Groups to the Admin 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.

# kubectl get clusterrolebinding kasten-io-k10-k10-admin -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2020-10-31T23:48:23Z"
  labels:
    app: k10
    app.kubernetes.io/instance: k10
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: k10
    helm.sh/chart: k10-20201031.47140.1f7faf3
    heritage: Tiller
    release: k10
  name: kasten-io-k10-k10-admin
  resourceVersion: "2124569"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kasten-io-k10-k10-admin
  uid: 2e8b39ec-925b-469d-8232-c8dbdc12c1bf
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:admins

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 production+admin@kasten.io 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.

Basic User

Defining a Cluster Role for 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.

# kubectl get clusterrole k10-basic -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2020-10-31T23:48:23Z"
  labels:
    app: k10
    app.kubernetes.io/instance: k10
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: k10
    helm.sh/chart: k10-20201031.47140.1f7faf3
    heritage: Tiller
    release: k10
  name: k10-basic
  resourceVersion: "2124566"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/k10-basic
  uid: d720cceb-890a-444e-b78d-56fcf7851d41
rules:
- apiGroups:
  - actions.kio.kasten.io
  resources:
  - backupactions
  - backupactions/details
  - restoreactions
  - restoreactions/details
  - exportactions
  - exportactions/details
  - cancelactions
  verbs:
  - '*'
- apiGroups:
  - apps.kio.kasten.io
  resources:
  - restorepoints
  - restorepoints/details
  - applications
  - applications/details
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get

Binding Users to the Basic Role

To assign the Basic role to a specific user named production+basic@kasten.io, 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

# kubectl get rolebinding k10-basic-user -n k10-basic-user-ns-1  -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-10-26T21:19:16Z"
  name: k10-basic-user
  namespace: k10-basic-user-ns-1
  resourceVersion: "2125481"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/k10-basic-user-ns-1/rolebindings/k10-basic-user
  uid: 11c423d3-98a2-40f5-9bee-cd915df8436b
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-basic
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: production+basic@kasten.io

Screenshots for the Basic User

The user named production+basic@kasten.io 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 production+basic@kasten.io 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.

Config User

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.

K10 creates a Cluster Role name k10-config-view.

# kubectl get clusterrole k10-config-view -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2020-10-31T23:48:23Z"
  labels:
    app: k10
    app.kubernetes.io/instance: k10
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: k10
    helm.sh/chart: k10-20201031.47140.1f7faf3
    heritage: Tiller
    release: k10
  name: k10-config-view
  resourceVersion: "2124565"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/k10-config-view
  uid: 4fa42b96-e68a-4aee-bfb0-d74918cb44be
rules:
- apiGroups:
  - config.kio.kasten.io
  resources:
  - profiles
  - policies
  verbs:
  - get
  - list

This Cluster Role defines a rule that says that only the Get and List operations are permitted on the profiles and policies resources within the api group named config.kio.kasten.io

Binding Users to the Config role

To assign this role to a specific user named production+config@kasten.io, this Cluster Role Binding is created:

# kubectl get clusterrolebinding k10-config-user-binding -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2020-10-26T21:19:17Z"
  name: k10-config-user-binding
  resourceVersion: "2125488"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/k10-config-user-binding
  uid: 7470ee0f-a371-49e3-8511-688ace226df7
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-config-view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: production+config@kasten.io
  namespace: kasten-io

Screenshot for the Config User

The user named production+config@kasten.io 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.

Conclusion

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!

References

https://kubernetes.io/docs/reference/access-authn-authz/rbac/
https://docs.kasten.io/latest/access/rbac.html

Originally published at
https://blog.kasten.io/how-to-configure-k10-with-rbac-for-multi-tenant-environments

Onkar Bhat is an Engineering Leader at Kasten (https://kasten.io) . His focus has been in the areas of authentication, multi-tenancy and multi-cluster management for data protection in Kubernetes. He previously worked at Big Switch networks (acquired by Arista Networks), NetApp and Cisco. Onkar received his MS from Carnegie Mellon University.

https://www.linkedin.com/in/onkarbhat/

https://twitter.com/onkarbhat