Part 7: Deploying Identity and Access Management in Kubernetes with Keycloak
Kubernetes Authentication Explained: Deploying Keycloak for Identity and Access Management
Kubernetes Cluster Build Series
This article is part of a step-by-step series on building a production-style Kubernetes cluster from scratch.
Series so far:
Part 3 – Installing Kubernetes and Bootstrapping the Cluster (kubeadm + Calico)
Part 7 - Deploying Identity and Access Management in Kubernetes with Keycloak (Current Article)
Each part builds on the previous one, so it is recommended to follow the series in order.
Why identity matters in application deployed on Kubernetes?
At this stage in the series, the Kubernetes cluster can already run workloads, provide persistent storage, and support object storage.
However, most real platforms also need a way to manage:
Users
Logins
Application authentication
Role-based access
Without a centralized identity provider, every application ends up managing its own usernames and passwords. This quickly becomes difficult to operate and insecure.
This is why many Kubernetes platforms introduce an identity provider such as Keycloak.
Authentication V/S Authorization
Before deploying Keycloak, it is useful to understand two related but different concepts:
Authentication
Authentication answers:
“Who are you?”
Example:
A user enters a username and password
The platform confirms the identity
Authorization
Authorization answers:
“What are you allowed to do?”
Example:
A user may be allowed to view dashboards
Another user may also be allowed to modify settings
Authentication identifies the user.
Authorization determines permissions.
Keycloak primarily helps with authentication and identity management though authorization is also possible through role-based access control.
What is Keycloak?
Keycloak is an open-source identity and access management platform.
It provides:
Login pages
User management
Single Sign-On (SSO)
OAuth2 and OpenID Connect support
Integration with many applications
Instead of every application handling its own authentication, applications can delegate that responsibility to Keycloak.
This makes platform management much simpler.
For more: Keycloak
Why Keycloak is commonly used in Open-Source Kubernetes environments
Keycloak is popular in Kubernetes environments because:
It can run entirely inside the cluster
It integrates well with cloud-native applications
It supports modern authentication standards
It works well for internal platforms and developer environments
Typical use cases include:
Grafana login
Internal dashboards
Kafka UI
Custom applications
API authentication
Keycloak Deployment in Kubernetes
Creating a dedicated namespace
Identity services should usually run in their own namespace.
This makes them easier to manage and isolate from other workloads.
Example namespace:
kubectl create namespace keycloak-system
You can choose any namespace name, but using a dedicated namespace is recommended.
Deploying Keycloak
There are multiple ways to deploy Keycloak in Kubernetes:
Raw manifests
Helm charts
Operators
For most clusters, the easiest and most maintainable approach is either:
Official Helm chart
Kubernetes manifests with a Deployment and Service
A minimal deployment usually includes:
Keycloak container
Service for internal access
Optional persistent storage
Optional ingress or route
Typical deployment flow:
Create namespace
Apply deployment manifest or Helm chart
Wait for pods to start
Verify service availability
For the sake of simplicity, we'll do the QuickStart deployment:
kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/refs/heads/main/kubernetes/keycloak.yaml
You can also download the YAML file and make changes to necessary variables like KC_HOST and configuration like pointing to a persistent PostgreSQL database to store Keycloak's data instead of the default temporary storage pod.
Verification:
kubectl get pods -n keycloak-system
kubectl get svc -n keycloak-system
You should see:
Keycloak pod in
RunningstateA PostgreSQL pod in
RunningstateService exposed inside the cluster
For more: Kubernetes - Keycloak
Accessing Keycloak
Once deployed, Keycloak is typically accessed through:
NodePort
LoadBalancer
Ingress
Reverse proxy
The recommended production approach is to expose it through an ingress with TLS enabled.
When you open the Keycloak URL, you should see:
Login page
Admin console
Realm management interface
The first login usually uses an initial admin account created during deployment.
Understanding Realms in Keycloak
One of the first concepts in Keycloak is the idea of a realm.
A realm is an isolated identity domain.
For example, you might create:
A realm for internal employees
A realm for developers
A realm for a specific application
Each realm has its own:
Users
Roles
Authentication settings
This allows a single Keycloak deployment to serve multiple applications safely.
Basic validation after deployment
After Keycloak is running, validate:
Pod remains stable
Service is reachable
Admin login works
New realm can be created
A test user can be added
If these steps work, Keycloak is functioning correctly.
Common deployment issues
Typical problems include:
Pod stuck in
CrashLoopBackOffMissing database configuration
Service not reachable
Ingress misconfiguration
Browser showing login page but failing after authentication
Keycloak may also take longer to start than typical applications because it initializes configuration and databases during startup.
Always wait a few minutes before assuming the deployment failed.
Should Keycloak use persistent storage?
Yes.
Identity systems store:
Users
Roles
Authentication settings
Configuration
Without persistent storage, all of that is lost if the pod is recreated.
This means Keycloak should ideally use:
PersistentVolumeClaims
The Longhorn storage layer configured earlier in the series
This is one of the first practical uses of the storage layer built in Part 5.
How Keycloak fits into the rest of the platform?
Keycloak becomes more valuable as more services are added.
Later in the series, Keycloak could be integrated with:
Grafana
Internal dashboards
Kafka management interfaces
Application APIs
CI/CD systems
This turns the Kubernetes cluster into a more complete internal platform rather than just a collection of workloads.
What’s next
In the next part, we will deploy Kafka inside Kubernetes using Strimzi and build the messaging layer of the platform.
