Excellent topic we are reviewing, in the previous post we reviewed everything related to the Keycloak configuration for centralized user management through OpenID leaving it ready for integration with Kasten K10 y Kasten K10 Multi-Cluster Manager. Therefore, in this post we will see step by step the configuration of the Clusterroles, Roles and groups necessary for management via RBAC of Kasten K10.
Configuration Kasten keycloak
*** 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 modify directly in the cluster of kubernetes user permissions over time, so all the management of user creation, groups, group assignment is done in Keycloak. ***
we should coneconnect us to the primary cluster of Kubernetes where is it installed Kasten K10 and we will proceed to the Authentikation configuration with Keycloak, but before, we need to extract the “Secret” from our “Client” kasten in the “Credentials” menu replacing the variable “auth.oidcAuth.clientSecret”, (replace SuperDuperClientSecret) and of course replacing the values with your DNS or IP data, executing the following command (for security, remove 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://kast24xsiempre.com/en/" --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 will see what each of these variables means:
- --set auth.oidcAuth.enabled=true / We enable OpenID Authentikation
- –set auth.oidcAuth.providerURL=”https://auth.24xsiempre.com/auth/realms/kasten" / Url to Authenticate
- –set auth.oidcAuth.redirectURL="https://kast24xsiempre.com/en/" / application url K10
- --set auth.oidcAuth.scopes=”groups profile email” / Client Scopes to validate
- --set auth.oidcAuth.groupClaim=”groups” / Client Scope Group Name
- --set auth.oidcAuth.prompt=”login” / Login Message
- --set auth.oidcAuth.clientID=”kasten" / Name of the Client in the Realm created.
- --set auth.oidcAuth.clientSecret=”SuperDuperClientSecret” /Client secret
- --set auth.oidcAuth.usernameClaim=”email” / In case of email Authentikation
- --reuse-values / Reuse values already configured
- --set externalGateway.create=true / Reconfigure gateway service in K10 for remote access
An important piece of information if you already have an Authentikation method configured for Kasten, it is better to disable it and then run the above command on error.
Users access
As we already have everything configured, the creation of the user that we made in the previous post, we only have to enter the web interface of Kasten, let's remember the user detail:
- User: kastenadmin
- Password: SuperDuperPassword or the one that has been applied
- Group: k10:admins
Now we will only enter the Url of Kasten in my case https://kasten.24xsiempre. Com /k10/#/ and it will redirect us to the Keycloak login form in the realm of Kasten, we enter the credentials:
And we will be able to observe that we have a successful entry and with all the permits since we belong to the group "k10:admins” and we didn't have to edit any ClusterRole or Roles.
To confirm the permissions, it is possible to validate them graphically either by viewing “permissions” “unrestricted” or entering the primary cluster, then “Cluster Settings”, then “Support” and finally click on “View Current User Details” and you will be able to view all the permissions of that user and the group it belongs to:
So far so good, but what if the user “kastenadmin” do we change the group? We will go back into Keycloak and change the group”k10:admins” to “k10:BASIC"
And we enter again Kasten we will see the following:
The user "kastenadmin” no longer belongs to “k10:admins” and now belongs to “k10:basic” which is not configured with its respective ClusterRoleBinding, RoleBinding associated to any ClusterRole or Role.
Creation of Access Roles in Kasten K10
As we saw before, we have configured the primary cluster of Kasten K10 as also kasten Multi-Cluster Manager, we will start by reviewing access to only the primary cluster without the need to access the Multi-Cluster roles.
User Administrator
So if you don't need Multi-Cluster Manager, you can manage users with Keycloak. Therefore we will create a group in Keycloak to access the cluster named “k10:only” and we will associate it to the user “kastenadmin ”
And now via SSH we will list the ClusterRoles:
kubectl get clusterrole | grep k10
We will generate 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 we apply it with the command:
kubectl apply -f k10solo.yaml
We will confirm the creation of the ClusterRoleBinding listing with the command:
kubectl get clusterrolebindings | grep k10
And if we again enter Kasten K10 can we validate that we only have access to the production cluster as an administrator, now why do I have access as an administrator? On the line 5 of the yaml file that we generated is the reference to the ClusterRole “k10-admin” which guarantees us the role. When accessing we will see that we have access to everything, except for the following error:
what it is telling us Kasten K10 is that you do not have permissions on the namespace "kasten-io” to consult or list the deployments and know the status of the services, for them we must add the group “k10:only” in the Role “k10-ns-admin” found 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 do it with 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 will confirm the creation of the RoleBinding listing with the command
kubectl get rolebindings -n kasten-io
And now we validate the permissions again and that the error of the service states of Kasten K10:
And we already have everything in an excellent color :). Now what if I want a user who can run but can't modify the settings?ones?
User Operator
As we have seen before, we are going to create a group in keycloak named “k10:operator” and assign it as a single group again to the user “kastenadmin”.
What does an operator need, for example, that he can see all the applicationsones, you can see all the backup policies as well as the automatically generated reports, in turn, that you have access to create, edit backup policy but that DO NOT You can delete some resource or edit some configuration.
Therefore, we are going to create a ClusterRole that allows us to have the necessary permissions for the “Operator” role, We will 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 k10operatorclusterrole.yaml
As we can see in the file, the operator clusterrole user you don't have delete permissions, we validate the creation of the clusterrole:
kubectl get clusterrole | grep k10
Now we generate the clusterrolebinding to associate it with our user group “k10:operator"
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 it will be able to access but not delete, we will also add it 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, he will have the following message:
But if you want to create a backup policy you will be able to:
Or if you wanted to delete a “Location Profile” you will not be able to since you do not have the permission to do so and the delete button is disabled
This demonstrates that you can generate RBAC resources associated with groups by managing users directly from Keycloak, without the need to create local users or edit clusterroles / clusterrolebindings every time a user needs access to the platform. Kasten. But we are not done yet, we still need to review the RBAC of Kasten Multi-Cluster Manager, which we will see in the next post, Click Here!