Keycloak OIDC authentication for Kubernetes: how the API server trusts your identity provider
Engineers who reach Kubernetes clusters with shared or long-lived credentials make it hard to see who changed what, and harder to remove one person's access on the day they leave. The platform team usually wants each engineer to sign in with an individual identity and to have that access revoked centrally. This setup uses Keycloak as the OpenID Connect provider, and the Kubernetes API server validates the tokens Keycloak issues. Once a user signs in through kubectl, the cluster trusts a signed, short-lived token instead of a credential copied into a kubeconfig file that may never expire. That benefit only holds if token lifetimes, signing keys and issuer settings are chosen deliberately.
Kubernetes does not store normal user accounts. There is no User object to create for an engineer. When a request arrives with a bearer token, the API server authenticates it, and the username and group values it derives come from claims inside that token. Authorization is a separate step: RBAC decides what those identities may do, using Role and ClusterRole bindings that name users and groups. Keycloak therefore owns who someone is and which groups they belong to, while the cluster owns what each group can do. Plan both sides together. A groups claim that Keycloak emits but no RoleBinding references grants nothing, and a binding that names a group spelled differently from the claim fails without an obvious error.
The API server accepts OIDC settings in two ways. The flag-based method passes issuer, client and claim settings as API server command-line options, so every change requires restarting the control plane component. The structured AuthenticationConfiguration file, which the API server reads from a file you supply, places the issuer, audiences, claim mappings and claim validation rules in one document that can be reviewed and version controlled. Confirm with your Kubernetes distribution which method it supports and which release line it targets, because availability depends on the version you run. This page covers both methods, explains how claim mappings turn Keycloak fields into usernames and groups, and lists the checks to run after each change.
Before you configure either method, decide three things. First, which Keycloak realm and client will represent the cluster, and whether kubectl uses a public client with PKCE or a confidential client, since that changes how the kubeconfig is built. Second, which claim carries the username and which carries groups, and whether you accept the default prefixes or set your own. Third, who is allowed to sign in: a specific realm role, a single group, or any authenticated user in the realm. Expect the first rollout to take longer on the identity side than on the Kubernetes side, because the group structure in Keycloak is often the part nobody has written down.
What the cluster and Keycloak need before OIDC is switched on
Switching on OIDC changes how kube-apiserver validates every token it receives, so the cluster and the identity provider must be ready before any flags or AuthenticationConfiguration file are changed. The six items below connect the two systems and decide whether a restart can be done safely. Work through them with your platform and security teams before a change window is planned.
Supported Kubernetes release
Confirm that the cluster runs a minor release the project still supports. As of September 2026, the supported set is 1.35, 1.36 and 1.37, with end-of-life dates of February 28, 2027, June 28, 2027 and October 28, 2027, according to the Kubernetes releases page. Check the release notes for your exact version to confirm which OIDC options it supports. If the cluster runs an older release, plan the upgrade first, one minor version at a time, before enabling OIDC.
Keycloak realm reachable over HTTPS
Every control plane node must reach the Keycloak realm over HTTPS, because kube-apiserver fetches the OpenID discovery document and signing keys from the issuer to validate tokens. Test that access from each node itself, not from a workstation, since firewall rules, proxies and DNS often differ between hosts. Keycloak's production guidance calls for TLS on all communication and a reverse proxy in front of the server, so confirm that the public frontend hostname is the one the API server will use.
Dedicated client for the API server
Create a separate OpenID Connect client in the realm for the API server, apart from any application client. The API server validates tokens against an audience value, so that client ID must match the audience the kube-apiserver configuration expects, which limits which tokens the cluster accepts. Confirm with your Keycloak administrators whether kubectl will use a public client with PKCE or a confidential client. Record the client ID, scopes and the mapper that adds the username and groups claims before the cluster change begins.
Three control plane nodes behind a load balancer
The kubeadm high availability guidance describes stacked and external etcd topologies, and both call for at least three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443. The load balancer must send traffic to every control plane node and remove any node that fails its health check. Etcd should run with an odd number of members, and the Kubernetes documentation recommends five members in production. Confirm that the load balancer address matches the control plane endpoint and the certificate names in the cluster.
Rolling restart of kube-apiserver
Enabling OIDC means restarting kube-apiserver with new flags or a new configuration file, so the control plane layout must let one node restart while the others keep serving requests. Confirm that the load balancer has removed each node from rotation before its restart, and that the node is healthy again before the next one starts. Keep a copy of the current static pod manifest so that you can roll back quickly. Agree in advance how each node is reached if a bad configuration stops the API server from starting.
Issuer URL and CA trust chain
The issuer URL in the API server configuration must match the iss claim in Keycloak tokens exactly, including scheme, host, port and realm path. Confirm the exact issuer value and the CA trust chain for the Keycloak certificate with your security team before any change, because every control plane node must trust the chain Keycloak presents. A certificate from a private CA, or an intermediate certificate the server does not send, will cause validation to fail at startup or at first login. Record the chain and its expiry date with the change request.
Choosing between API server flags and the AuthenticationConfiguration file
The choice between API server OIDC flags and the AuthenticationConfiguration file matters less for day one than for the years that follow. Both approaches let kube-apiserver accept tokens issued by your Keycloak realm, so kubectl users can sign in with the same accounts they use elsewhere. The flags are the simpler starting point: a handful of arguments such as the issuer URL, client ID, and username and groups claim settings, set directly on the kube-apiserver command line. The structured file, passed to the API server through its authentication configuration flag, supports a more detailed setup, including multiple identity providers and claim rules that the flags cannot express. Confirm which option your target Kubernetes release supports with the flags you plan to use, and check whether any flag you rely on is marked deprecated in that release.
Whichever option you choose, changes take effect only after kube-apiserver restarts, and in a highly available control plane that restart must happen on each control plane node. A realm rename, a new client ID, or a corrected groups claim therefore becomes a rolling change across every node, not a single edit. That makes the location and management of the configuration more important than the initial choice. If the flags or the file live only on one node, the nodes will drift, and a request may succeed or fail depending on which API server answered it. Decide where the source of truth sits before go-live: in version control alongside your cluster manifests, in the kubeadm configuration that your build process applies, or in a managed platform's own configuration interface. Each has a different review path, rollback path, and owner.
Plan for the upgrade cycle now, because the authentication settings will be carried across it. Kubernetes releases roughly three times a year, and the project maintains only the three most recent minor releases, so an authentication setup that works today will need checking on each upgrade. Read the Kubernetes authentication documentation for your target release to confirm the exact field names, the supported issuer and claim options, and whether the structured file is available and stable in that version. Do not assume a field present in one release exists in the next. Record which configuration method you are using, the release it was validated against, and the test that proves a Keycloak token still maps to the expected user and groups after the upgrade.
Finally, decide which option you will still use after the next upgrade, not only which one is quickest to set up today. If you expect a second identity provider, stricter claim validation, or claim rules tied to specific audiences, the structured file is the better fit, and the flags may need replacing later. If your needs stay as one issuer with straightforward username and groups claims, the flags may remain adequate, but document the limits so a future change does not force an unplanned migration during an incident. Whichever path you choose, keep the Keycloak client settings, the API server configuration, and the RBAC bindings that map groups to roles reviewed together, since a claim change on either side changes who holds cluster permissions.
How Keycloak token claims map to Kubernetes users and groups
This table lists each setting that connects a Keycloak token to the Kubernetes username and groups fields, with the Keycloak side that produces it. Read it top to bottom as a build checklist, then confirm each exact expression against the Keycloak administration guide and the Kubernetes authentication docs for your release. The main takeaway is that the identity claim, the groups claim, the prefixes and the audience must agree across both systems before any user can sign in.
| Setting | What it controls | Keycloak side | What to confirm |
|---|---|---|---|
| Issuer URL | Tells the API server which Keycloak realm issues tokens and must match the iss claim exactly | Realm frontend URL and the issuer value in the realm's OpenID discovery document | Exact issuer string, including trailing slash rules, against the realm discovery endpoint |
| Audience | Accepts only tokens minted for the cluster client, so tokens for other applications are rejected | Dedicated client for kubectl, with an audience mapper so the aud claim includes the cluster client ID | Audience check settings in the Kubernetes authentication docs for your release |
| Username claim | Selects the token claim used as the Kubernetes username, commonly email or preferred_username | User attributes exposed to tokens through the client scope's default mappers | Whether the claim is unique and verified in your realm, since it becomes the identity key |
| Username prefix | Prevents a token user from colliding with built-in users such as system accounts | Not set in Keycloak; chosen on the API server side and applied to every mapped username | Whether to use an explicit prefix or the default behavior for your release |
| Groups claim | Names the token claim read as Kubernetes group membership | Group Membership mapper added to the client scope, with the token claim name set and full path turned off where short names are wanted | Exact mapper field names and whether the groups claim is emitted in ID or access tokens |
| Groups prefix | Keeps Keycloak group names from matching built-in Kubernetes groups such as system:masters | Keycloak group names stay unchanged; the prefix is added by the API server | Prefix value and how it appears in RoleBinding and ClusterRoleBinding subjects |
| Token type used | Determines which token kubectl sends and which claims the API server reads | Client scope and mapper placement decide whether claims appear in the ID token, the access token or both | Which token your kubectl OIDC plugin forwards for your Kubernetes release |
| Signing algorithm | Lets the API server verify token signatures from the realm's published keys | Realm keys used to sign tokens, exposed through the JWKS endpoint | Supported algorithms and key rotation behavior for your Keycloak and Kubernetes versions |
Keycloak OIDC authentication for Kubernetes setup sequence
This sequence takes a Keycloak realm from client definition to a verified group-based RBAC binding on a Kubernetes cluster. It produces a test user who signs in with Keycloak-issued tokens and receives only the access their group grants. Each step closes with a check that a reviewer can repeat.
Create the realm and OIDC client in Keycloak
The platform team creates a dedicated realm for cluster sign-in and a client for kubectl, choosing the client type and redirect settings that match the kubeconfig plugin the team plans to use. If Keycloak runs on Kubernetes, the same client can be declared with the Keycloak Operator's KeycloakOIDCClient resource so the definition lives in version control. Record the issuer URL and client ID, and store any client secret in the team's secrets store. Check: the realm's OpenID discovery document loads over HTTPS and lists the issuer value the API server will be configured to trust.
Add groups mapper and confirm token claims
Add a group membership mapper to the client so the access token carries a groups claim. Decide now whether group names appear as full paths or short names, because the API server and RBAC bindings must match that format exactly. Create a test user, add that user to a test group, and request a token. Check: decode the token and confirm the iss, aud, username claim and groups claim contain the values the API server will be configured to read.
Set OIDC settings on one control plane node
The cluster administrator sets the issuer URL, client ID, username claim and groups claim on a single control plane node, keeping a copy of the previous manifest so the change can be reverted. Choose between the older kube-apiserver OIDC flags and the structured AuthenticationConfiguration file, and confirm in the documentation for your Kubernetes version which option that version supports and how the file is loaded. Check: kube-apiserver restarts, its static pod reports ready, and its logs show no authentication configuration errors.
Roll the change to remaining control plane nodes
Apply the same settings to each remaining control plane node one at a time, waiting for each kube-apiserver to become healthy before moving to the next. Keep the load balancer in front of the API server in service so that healthy endpoints remain available during the rollout. Confirm every node receives identical files, because a request that reaches a node with stale settings will fail for some users. Check: each node loads the same authentication configuration, and a token from the test user is accepted repeatedly when requests pass through the load balancer address.
Add a kubeconfig entry for a test user
Create a kubeconfig user entry that uses the OIDC authentication plugin or exec credential helper the team has standardized on, pointing it at the issuer, client ID and client settings from the first step. Confirm how that plugin handles browser login and token refresh for your kubectl version. Sign in as the test user from a workstation that follows your access policy. Check: a read-only command such as listing namespaces returns a Forbidden response from the API server, which shows the token was accepted and the identity was mapped.
Bind test group to RBAC role and verify access
Create a RoleBinding that grants an existing, narrow role to the test group, using the group name exactly as it appears in the groups claim. Start with a read-only role in a single test namespace and widen the scope only after review. Check: from an administrator context, kubectl auth can-i with user and group impersonation returns the expected yes and no answers, and the test user's own kubectl commands produce the same results. Save the outputs in the change record.
Pairing Keycloak groups with RBAC so sign-in grants only the access each team needs
A successful Keycloak sign-in into the Kubernetes API server only establishes who the user is. What that user can do is decided by Kubernetes RBAC bindings, so the groups claim from Keycloak is only useful once it is bound to Roles or ClusterRoles that match a real team responsibility. Map each Keycloak group to the narrowest set of permissions that team needs, for example a namespace-scoped Role for an application team that can read pods and logs in its own namespace, and a separate ClusterRole for a platform group that manages cluster-wide resources. Write the mapping down before you create any binding, because the group name becomes the key that every later access decision depends on. Test every binding the way an attacker or a careless user would exercise it. Use kubectl auth can-i with the --as and --as-group flags to impersonate a user who belongs to only one group, and check both the permissions that should succeed and the many that should fail, including reads of Secrets, exec into pods, and changes to RoleBindings. Impersonation tests run against the live API server, so they confirm the actual effect of your bindings rather than what the YAML appears to say. Repeat the checks after every change to a group, a binding or the ClusterRole it references, and keep the results as evidence for your access reviews. Avoid binding cluster-admin, or any broad ClusterRole, to a group whose membership a user could influence. Check which claim the API server reads for groups and whether that claim can be edited by the user, by an attribute mapper that copies free-text profile data, or by a group that a self-service workflow can join. A value such as a team name or an email domain can look safe in a demo and still grant administrator rights when a user changes a profile field. Restrict admin bindings to a small, separately governed Keycloak group whose membership changes need approval, and confirm in Keycloak's admin console and your own sign-in tests which claims the access token actually carries. Group membership changes in Keycloak do not take effect on the Kubernetes side at once. The API server validates the token it receives, and an access token already issued keeps its group claims until it expires, so a user who is removed from a group can keep the old permissions for up to the access token lifetime. Revocation timing therefore depends on the token lifetime settings in the Keycloak realm and client, and on how long the user's kubeconfig or exec plugin keeps reusing a token. Set access token lifetimes deliberately, balancing the revocation window against the number of sign-in prompts your teams will tolerate, and document the chosen values so that an access removal has a known worst-case delay. Treat these values as hypotheses until you test them in your own environment. Ask your Keycloak and Kubernetes teams to confirm the access token lifetime, whether any session or refresh behavior extends effective access, and how quickly the API server rejects an expired token. Then remove a test user from a group, wait past the expected window, and confirm that the impersonated and real requests are denied. Record the observed delay and repeat the test after upgrades to either platform, since token and authorization defaults can change between releases.
Hardening the OIDC path between Keycloak and the API server
Keycloak issues the identity, and the Kubernetes API server decides what that identity can do, so the controls that matter sit on both ends and on the hops between them. The cards below cover transport, Keycloak exposure, API server configuration, RBAC, secret storage, and logging and metrics, in the order a platform team usually works through them.
TLS on every hop
Kubectl, Keycloak and the API server should all communicate over TLS, including the token and discovery endpoints the API server calls to validate tokens. Keycloak's production guidance calls for TLS on all communication and a reverse proxy with path restrictions in front of the server. Check that the issuer URL in the API server configuration matches the certificate name Keycloak presents, and that the API server trusts the CA that signed it.
Separate admin and public hostnames
Keycloak's production guide recommends exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Only the paths that kubectl users and the API server need should be reachable from outside your network, and the proxy should block administrative paths on the public host. Confirm this with a test from an unauthorized network segment before go-live.
Restricting API server configuration changes
OIDC settings live in API server flags or in the AuthenticationConfiguration file, so whoever can change them can decide which identity provider is trusted and which claims become usernames and groups. Limit write access to control plane nodes and manifests to a small group, log every change, and review the file in version control. A misconfigured issuer or audience can lock out all users, so keep a tested break-glass path with client certificates.
Least-privilege RBAC for groups
A groups claim is only as safe as the bindings that consume it. Avoid mapping Keycloak groups to cluster-admin, edit across all namespaces, or wildcard verbs, and bind each group to namespace-scoped roles where possible. Use the groups prefix setting in the OIDC configuration so that identity-provider groups cannot collide with built-in Kubernetes groups such as system:masters. Review bindings after each Keycloak group change.
Encryption at rest for Secrets
Kubernetes stores Secrets unencrypted in etcd by default. Any OIDC client secret, kubeconfig material or token handled through a Secret needs encryption at rest, configured through an EncryptionConfiguration on the API server, along with restricted list and watch access. Confirm that etcd snapshots are encrypted too, because backups carry the same data. Consider an external store through the Secrets Store CSI Driver if key management must sit outside the cluster.
Audit logging of authentication and authorization
Kubernetes audit logging records requests to the API server, and Keycloak's event logging records sign-in events and failures. Together they let you trace a kubectl session from the token issued by Keycloak to the resource changed in the cluster. Decide the audit policy level for sensitive resources such as Secrets and RBAC objects, set retention, and confirm that logs are shipped off the cluster and cannot be edited by cluster admins.
Keycloak metrics with Prometheus
When Keycloak starts with metrics enabled, it exposes Prometheus-format metrics at /metrics on its management interface, with optional HTTP request and cache histograms. Scrape that endpoint from inside your network only, since the management interface should not sit on the public hostname. Alert on sign-in failure trends, token endpoint latency and pod restarts, because an unhealthy Keycloak stops every kubectl login at once.
Why kubectl sign-in or API access fails after OIDC is enabled
This table pairs each common failure with its likely cause, the check to run first, and the fix. Work down the rows in order, because several symptoms look alike until you confirm which layer is failing. The main takeaway is that a successful Keycloak sign-in proves very little on its own; the API server still has to trust the issuer, match the token claims exactly, and find an RBAC binding.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Login redirect or token validation fails with a TLS or DNS error | The API server cannot reach the Keycloak issuer URL, or it does not trust the certificate chain that Keycloak presents | From each control plane node, fetch the issuer's /.well-known/openid-configuration and the JWKS URI, then compare the certificate chain with the CA bundle passed to the API server | Correct DNS or routing from the control plane, and supply the full CA chain to the API server through its OIDC CA file setting |
| Every token is rejected with an issuer mismatch | The issuer URL configured on the API server differs from the iss value in the token, including a trailing slash, hostname case, or a different realm path | Decode a token issued by Keycloak and compare its iss claim character by character with the issuer value in the API server configuration | Set the API server issuer to the exact iss value Keycloak emits, and keep it identical across all control plane nodes |
| Token is rejected with an audience error | The audience configured for the API server does not match the aud claim, which normally carries the Keycloak client ID used by kubectl | Decode the token and read the aud claim, then confirm the client ID the kubeconfig requests and the audience the API server expects | Align the client ID in the kubeconfig, the Keycloak client, and the API server audience setting so all three match |
| User signs in but has no groups inside Kubernetes | The groups mapper is not attached to the client scope that kubectl requests, so the groups claim is absent from the token | Decode the access or ID token and look for the groups claim; then check whether the mapper is on the client scope used by the kubeconfig | Add a group membership mapper to the client scope, set the claim name to match the API server groups setting, and sign in again to get a new token |
| Users unexpectedly gain cluster-admin style rights | A Keycloak group name collides with a built-in Kubernetes group such as system:masters, so the API server grants that group's privileges | List every group value Keycloak can emit and compare them with built-in Kubernetes groups, and review any ClusterRoleBinding that references those names | Apply a group prefix in the API server configuration, rename Keycloak groups to a dedicated namespace, and remove any binding that grants rights to unexpected subjects |
| Forbidden errors after a successful sign-in | The user authenticates correctly, but no RoleBinding or ClusterRoleBinding names the user or their group, so authorization denies the request | Run kubectl auth can-i with the --as and --as-group flags against the target resource, and inspect the bindings that reference the subject | Create RBAC bindings for the Keycloak user or group names, scoped to the namespaces and verbs each team needs |
| Requests succeed on some attempts and fail on others | A control plane node was missed during rollout, so one kube-apiserver still runs the old authentication configuration and answers some requests | Query each API server directly and compare its running flags or AuthenticationConfiguration file, then check that the load balancer health checks show every node | Roll the identical configuration to every control plane node, restart each kube-apiserver, and re-test through the load balancer and against each node |
Questions teams ask before they hire help with Keycloak OIDC for Kubernetes
How much does Keycloak OIDC authentication for Kubernetes cost to implement?
DeployOpen does not publish a price list. A quote follows from a written scope, and the main cost drivers are the number of clusters, the number of control plane nodes and their topology, whether Keycloak is already running in production with realms and clients in place, the group and RBAC model you need, and how much testing you want. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ask for the quote to list each cluster separately, the test plan, the Keycloak changes, the documentation handover and anything excluded. Recurring costs come from upgrades and any support retainer you choose, so ask for those as separate line items.
How long does a Keycloak OIDC integration for Kubernetes take to deliver?
The duration is set by the written scope, not by a fixed template. The biggest factors are how many clusters must be integrated, whether each cluster's API server can be reconfigured in your change process, how much of the Keycloak realm, client and group model already exists, and how many test rounds your security and platform teams require before production. A single non-production cluster with an existing Keycloak client moves much faster than a fleet that needs a new group model and sign-off from several approvers. Ask the partner to state the schedule dependencies in the scope, especially your change windows and the dates when your Keycloak and cluster owners are available.
What does our team need to provide before a Keycloak OIDC project starts?
You need to provide four things. First, access to the clusters, including the ability to change kube-apiserver configuration through your distribution or infrastructure tooling, and a non-production cluster for testing. Second, Keycloak admin rights, or a named admin who can create or update a realm, a client and the token mappers that emit username and groups claims. Third, a group model that states which Keycloak groups map to which Kubernetes roles and namespaces, and who approves changes to it. Fourth, a test plan that lists the users, roles and failure cases to verify, along with the people who will run the tests and sign off.
Can a platform team set up Keycloak OIDC for Kubernetes on its own?
Yes. A platform team with access to a test cluster, a Keycloak instance and the upstream Kubernetes and Keycloak documentation can implement OIDC authentication without a partner. The work is well defined: configure a Keycloak client for kubectl, expose the username and groups claims, point the API server at the issuer, and bind Keycloak groups to RBAC roles. Teams usually struggle with the details, such as exact issuer URLs, audience values, TLS trust for the issuer certificate, claim prefixes and the group names used in RoleBindings. A partner adds value through review, a documented test plan and a handover that your team can run after go-live. Test everything on a non-production cluster first.
What is the difference between API server OIDC flags and the structured authentication file?
The OIDC flags on the kube-apiserver command line configure a single identity provider directly in the API server startup arguments. The structured AuthenticationConfiguration file moves that provider definition into a configuration file that the API server reads, which makes it easier to describe claim mappings and to manage more than one issuer in a structured way. Confirm which method your Kubernetes minor version and distribution support before you design the change, because support and reload behavior vary by version. Whichever method you use, plan the API server restart or reload as a controlled change, test it on one control plane node first, and keep a documented rollback path that restores the previous configuration.
What breaks when the username or groups claim is misconfigured in Keycloak?
Most failures look like authentication success followed by no access, or access under unexpected names. Check that the issuer URL in the Kubernetes configuration matches the issuer in the Keycloak token exactly, including the realm path and trailing slashes. Confirm that the audience matches the client ID that kubectl uses, that the token contains the username and groups claims you configured, and that the API server trusts the certificate chain of the Keycloak endpoint. Also check claim prefixes, because a prefix mismatch causes RoleBindings to silently fail to match. Finally, confirm that group names in Keycloak match the subjects in your RoleBindings character for character, and that a user who is in no group receives only the access you intend.
What is one-time work and what recurs after a Keycloak OIDC integration goes live?
The one-time work covers the design of the group and RBAC model, the Keycloak client and mapper configuration, the API server change, the test runs and the documentation handover. Recurring work covers the changes that come from the two products. Keycloak plans four minor releases a year and a major release every two to three years, and it says breaking changes in a minor release will be opt-in, so each release still needs a review of the client and mapper settings. Kubernetes also ships roughly three minor releases a year. Ask for a quote that separates the initial build from an upgrade allowance and from any support retainer, and state who runs each recurring task.
How does the Kubernetes version skew policy affect OIDC upgrades?
The version skew policy requires kube-apiserver to be upgraded one minor version at a time, and it must be upgraded before kube-controller-manager, kube-scheduler and the kubelets. Kubelets may run up to three minor versions behind the API server. For OIDC, this means every Kubernetes minor upgrade is also an authentication change window, because the authentication configuration must still be valid for the new API server version. Check the release notes for the target minor version before each upgrade, test the OIDC settings on a non-production cluster at that version, and confirm that the Keycloak version you run is supported with it. Keep the upgrade order in the runbook so that each control plane node is updated and verified before the next one.
How DeployOpen works on this
DeployOpen plans, builds and supports Keycloak OIDC authentication for Kubernetes inside your own clusters and cloud accounts or data centers. The work starts with a written scope covering the API server configuration, the Keycloak client, claim mapping and RBAC, and it runs through testing and documented handover before any ongoing support is agreed.
How we scope
- Confirm your Kubernetes distribution and version, since API server OIDC settings depend on the cluster build
- Agree whether authentication uses API server flags or the structured AuthenticationConfiguration file
- Define the username and groups claims, and the RBAC bindings each Keycloak group maps to
How we build
- Configure the Keycloak realm, OIDC client, audience and groups mapper for kubectl and API server access
- Apply the API server authentication settings and test token validation through each control plane node
- Test kubectl login, group-based RBAC denial and access paths, and document the results before handover
How we hand over
- Deliver the realm and client configuration, API server manifests and RBAC bindings as versioned artifacts
- Provide a runbook covering token lifetimes, certificate rotation, key rollover and lockout recovery steps
- Walk your platform and security teams through the configuration and the evidence gathered during testing
How we support
- Review the configuration again when you upgrade Kubernetes or Keycloak, since both change independently
- Offer ongoing support, upgrades and continuous testing as a retainer agreed in writing
- Confirm with your Kubernetes distribution vendor which authentication options it supports before you commit
