Introduction
Managing multiple Kubernetes clusters in any environment comes with its fair share of challenges, and one of the most crucial aspects is ensuring proper authentication and authorization across them. In my environment, I run different Kubernetes distributions, including k3d clusters, each in a separate network. While working on this setup, I was exploring a use case to centralize access management and RBAC across all clusters without needing separate Identity Providers(IDPs) for each one. This blog captures my observations and my approach to solving the use case using Rancher Server and Keycloak.
In this blog, I will share only the key configurations required to get authentication and RBAC working using Rancher Server and Keycloak. We will skip the full installation process and focus on the parts that matter to set up secure access management.
The Use Case: Why Centralized Management Matters
Consider this scenario: You have three Kubernetes clusters. Each serving a different purpose such as development, testing, and production. Managing users and permissions manually in each cluster quickly becomes inefficient. Instead, you would want an approach where:
- Authentication is handled by a single IDP(Keycloak in this case) for all clusters.
- Authorization policies(RBAC) are managed centrally via rancher-server, allowing you to define access
- Granular control over resources, such as granting read-only access to users in a specific namespace of a specific cluster.
- This setup ensures consistency and reduces administrative overhead.
Environment Overview
Here is what my environment looks like:
- Three Kubernetes clusters: alpha, beta and test-k8s-cluster
- Clusters are on different networks
- Keycloak serves as the centralized IDP for authentication
- Rancher Server manages the clusters and their RBAC configuration
To deploy Kubernetes clusters locally for testing purpose, you can follow this link.
Keycloak Configuration: Setting Up Authentication
In Keycloak, we only need to configure a realm, users, groups, and a client to integrate with Rancher Server.
- Creating a Realm for Rancher
- In Keycloak, a realm represents a space to manage users, roles, and authentication. I created a new realm specifically for the Rancher use case.
- Creating Users and Groups
- To control access at a granular level, I created a few users and assigned them to groups. The admin1 user was part of all groups to facilitate testing, and the pbandark user was part of the Dev group, which I used for validation.
- Configuring a Keycloak Client for Rancher
- The client in Keycloak is what allows Rancher to authenticate users. Key settings include:
- Client ID: Set to match the Rancher configuration.
- Protocol: OpenID Connect.
- Redirect URI: Add the callback URI for Rancher.
- Mapper Settings: Ensure that group membership is passed to Rancher for RBAC.
- The client in Keycloak is what allows Rancher to authenticate users. Key settings include:
Rancher Configuration: Integrating Keycloak
Now that Keycloak is ready, we need to configure Rancher to use it for user authentication.
- Importing Kubernetes Clusters
- I imported the Kubernetes clusters(alpha, beta and test-k8s-cluster) into rancher-server.
- Adding Keycloak as an Authentication Provider
Setting Up RBAC: Assigning Granular Permissions
With authentication working, the next step is to configure RBAC policies. Here is an example of how I set this up:
- Users in the Dev group should have read-only access to resources in the trinity namespace within the alpha Kubernetes cluster.
Steps to Implement This:
- Logged in to Rancher using the admin1 Keycloak user.
- Navigated to the imported cluster(alpha) and selected the trinity namespace.
- Added the Dev group with read-only permissions.
Now, any user in the Dev group can only view resources in the trinity namespace and is restricted from performing other actions.
Validation: Testing the Setup
To verify the setup, I used kubectl as a user “pbandark” belonging to the “Dev group“ and tested access across various namespaces:
- Attempting to list pods in the default namespace (denied):
[root@bastion alpha]# kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "u-mznb4f6zus" cannot list resource "pods" in API group "" in the namespace "default"- Attempting to list nodes (denied):
[root@bastion alpha]# kubectl get node
Error from server (Forbidden): nodes is forbidden: User "u-mznb4f6zus" cannot list resource "nodes" in API group "- Listing pods in the trinity namespace (allowed):
[root@bastion alpha]# kubectl get pod -n trinity -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-676b6c5bbc-szwxb 1/1 Running 0 26s 10.42.1.16 k3d-alpha-agent-1 <none> <none>- Attempting to execute commands in a pod (denied):
[root@bastion alpha]# kubectl exec -it nginx-676b6c5bbc-szwxb -n trinity -- bash
Error from server (Forbidden): pods "nginx-676b6c5bbc-szwxb" is forbidden: User "u-mznb4f6zus" cannot create resource "pods/exec" in API group "" in the namespace "trinity"These results confirm that the RBAC policies were successfully enforced. The user could only view resources in the trinity namespace and was restricted from performing actions beyond the assigned scope.
Conclusion
By using Rancher Server and Keycloak, you can centralize and simplify access management across multiple Kubernetes clusters, making it easier to enforce security policies and control access. This setup ensures consistency, reduces manual configuration, and provides fine-grained control over who can do what in your clusters.
To integrate Microsoft Entra ID with Keycloak for Kubernetes Access, you can refer this blog.
