Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 2

Excellent topic we’re reviewing — in the previous post we reviewed everything related to configuring Keycloak for centralized user management through OpenID, preparing it for integration with Kasten K10 and Kasten K10 Multi-Cluster Manager. So in this post we will go through step-by-step configuration of the ClusterRoles, Roles and groups needed to manage Kasten K10 via RBAC.

Kasten Keycloak Configuration

#

\\\* The idea of this series is to explain how to generate the groups, roles, clusterroles and other resources associated with RBAC, without the need to be directly modifying user permissions in the Kubernetes cluster over time. This way, all user creation, group creation and group assignment is done in Keycloak. ***

We must connect to the primary Kubernetes cluster where Kasten K10 is installed and then configure the authentication with Keycloak. But first, we need to extract the “Secret” from our “kasten” Client in the “Credentials” menu and replace it in the “auth.oidcAuth.clientSecret” variable (replace SuperDuperClientSecret), replacing the values with your own DNS or IP data. Run the following command (for security I removed part of the secret):

helm upgrade k10 kasten/k10 --namespace=kasten-io --set auth.oidcAuth.enabled=true --set auth.oidcAuth.providerURL="https://auth.24xsiempre.com/auth/realms/kasten" --set auth.oidcAuth.redirectURL="https://kasten.24xsiempre.com/" --set auth.oidcAuth.scopes="groups profile email" --set auth.oidcAuth.groupClaim="groups" --set auth.oidcAuth.prompt="login" --set auth.oidcAuth.clientID="kasten" --set auth.oidcAuth.clientSecret="SuperDuperClientSecret" --set auth.oidcAuth.usernameClaim="email" --reuse-values --set externalGateway.create=true

Now we’ll see what each of these variables means:

• –set auth.oidcAuth.enabled=true / Enables OpenID authentication
• –set auth.oidcAuth.providerURL=“https://auth.24xsiempre.com/auth/realms/kasten" / Authentication URL
• –set auth.oidcAuth.redirectURL=“https://kasten.24xsiempre.com/" / K10 application URL
• –set auth.oidcAuth.scopes=“groups profile email” / Client Scopes to validate
• –set auth.oidcAuth.groupClaim=“groups” / Name of the Client Scope group
• –set auth.oidcAuth.prompt=“login” / Login prompt message
• –set auth.oidcAuth.clientID=“kasten” / Name of the Client in the created Realm
• –set auth.oidcAuth.clientSecret=“SuperDuperClientSecret” / Client secret
• –set auth.oidcAuth.usernameClaim=“email” / In case of email-based authentication
• –reuse-values / Reuse already configured values
• –set externalGateway.create=true / Reconfigures the K10 gateway service for remote access

An important note: if you already have an authentication method configured for Kasten, it’s better to disable it and then run the previous command in case of errors.

User Access

#

Since we already have everything configured — including the user we created in the previous post — we just need to log in to the Kasten web interface. Let’s recall the user details:

• User: kastenadmin
• Password: SuperDuperPassword or whatever was applied
• Group: k10:admins

Now we will access the Kasten URL (in my case https://kasten.24xsiempre.com/k10/#/) and it will redirect us to the Keycloak login form in the kasten realm. We enter the credentials:

And we’ll see that we have a successful login with all permissions, since we belong to the “k10:admins” group and we didn’t have to edit any ClusterRole or Roles.

To confirm the permissions, you can validate them graphically by either viewing “permissions” “unrestricted” or entering the primary cluster, then “Cluster Settings”, then “Support” and finally clicking on “View Current User Details”. You’ll be able to see all the permissions of that user and the group they belong to:

So far so good, but what if we move the “kastenadmin” user to a different group? We’ll enter Keycloak again and change the group from “k10:admins” to “k10:basic”:

And when we log in to Kasten again, we’ll see the following:

The “kastenadmin” user no longer belongs to “k10:admins” and now belongs to “k10:basic”, which is not configured with its respective ClusterRoleBinding or RoleBinding associated with any ClusterRole or Role.

Creating Access Roles in Kasten K10

#

As we saw earlier, we have the Kasten K10 primary cluster configured, as well as Kasten Multi-Cluster Manager. We’ll start by reviewing access only to the primary cluster without the need to access Multi-Cluster roles.

Administrator User

#

In case we don’t need Multi-Cluster Manager, it’s possible to manage users with Keycloak. So we’ll create a group in Keycloak to access the cluster, named “k10:solo”, and associate it with the user “kastenadmin”:

And now, via SSH, we’ll list the ClusterRoles:

kubectl get clusterrole | grep k10

We’ll create a YAML file with the following content:

nano k10solo.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-solo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:solo

And then apply it with the command:

kubectl apply -f k10solo.yaml

We’ll confirm the creation of the ClusterRoleBinding by listing with the command:

kubectl get clusterrolebindings | grep k10

And if we log in to Kasten K10 again, we’ll be able to validate that we only have access to the production cluster as administrator. Now, why do I have access as administrator? On line 5 of the YAML file we generated, there is a reference to the ClusterRole “k10-admin” which grants us the role. When accessing, we’ll see that we have access to everything, except for the following error:

What Kasten K10 is telling us is that it doesn’t have permissions over the “kasten-io” namespace to query or list deployments and know the status of the services. For this we must add the “k10:solo” group to the “k10-ns-admin” Role in that namespace. To list the role:

kubectl get roles -n kasten-io

There are always several ways to edit these roles — you can edit it directly with the command kubectl edit roles k10-ns-admin -n kasten-io or use the following yaml:

nano ns-admin-k10solo.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k10-k10-ns-solo
  namespace: kasten-io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:solo

kubectl apply -f ns-admin-k10solo.yaml

We’ll confirm the creation of the RoleBinding by listing with the command:

kubectl get rolebindings -n kasten-io

And now we’ll validate the permissions again, checking that the Kasten K10 service status error no longer appears:

And now we have everything in a great color :). Now, what if I want a user who can execute but cannot modify the configurations?

Operator User

#

As we’ve seen before, we’re going to create a group in Keycloak called “k10:operador” and assign it as a single group again to the user “kastenadmin”.

What does an operator need, for example — that they can see all the applications, all the backup policies as well as the automatically generated reports, and also have access to create and edit backup policies but NOT to delete any resource or edit any configuration.

So we’re going to create a ClusterRole that allows us to have the permissions necessary for the “Operator” role. We’ll create the file with its respective content:

nano k10operadorclusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k10-operador
rules:
- apiGroups:
  - actions.kio.kasten.io
  - apps.kio.kasten.io
  - config.kio.kasten.io
  - reporting.kio.kasten.io
  - vault.kio.kasten.io
  resources:
  - '*'
  verbs:
  - get
  - list
  - patch
  - update
  - watch
  - create
- apiGroups:
  - cr.kanister.io
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - create
  - get
  - list

And we apply the file:

kubectl apply -f k10operadorclusterrole.yaml

As we can see in the file, the operator clusterrole does not have delete permissions. We validate the clusterrole creation:

kubectl get clusterrole | grep k10

Now we generate the clusterrolebinding to associate it with our user group “k10:operador”:

nano k10operadorbind.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-operador
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-operador
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:operador

And we apply the file:

kubectl apply -f k10operadorbind.yaml

We validate:

kubectl get clusterrolebindings | grep k10

And finally, since the user will be able to access but not delete, we’ll also add them to “ns-admin”:

nano k10operadornsadmin.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k10-k10-ns-operador
  namespace: kasten-io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:operador

We validate the creation:

kubectl get rolebinding -n kasten-io

We validate access to Kasten K10:

For example, if the user wants to delete a Backup Policy, they will receive the following message:

But if they want to create a backup policy, they will be able to do so:

Or if they want to delete a “Location Profile” they won’t be able to, since they don’t have permission for it and the delete button is disabled:

With this it’s demonstrated that you can generate RBAC resources associated with groups, managing users directly from Keycloak, without the need to create local users or edit the clusterroles / clusterrolebindings every time a user needs access to the Kasten platform. But we haven’t finished yet — we still need to review the RBAC of Kasten Multi-Cluster Manager, which we will cover in the next post, Click Here!

Related posts

#

• Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 1
• Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 3
• Kasten K10 Authentik
• How to Integrate Active Directory with Kasten K10 and OpenShift