Kubernetes on-prem clusters adopt public OIDC clients with PKCE for identity provider access control

Self-hosted Kubernetes clusters have historically lagged behind managed cloud services in access control. Managed Kubernetes typically ships with IAM or SSO integration, while on-prem clusters default to static client certificates or long-lived tokens. These credentials persist indefinitely, even after role changes or departures, because revocation requires manual cleanup of every distributed copy. This gap creates operational overhead and security vulnerabilities, particularly as teams grow and access requirements diversify.

The shift to identity providers via public OIDC clients addresses these issues by tying access to user accounts and group membership. Instead of distributing certificate files, administrators manage access through identity operations, adding or removing users from groups. This approach eliminates the need for per-user credential distribution and simplifies revocation. The integration relies on three components: kubectl with the kubelogin plugin, an identity provider like Keycloak, and kube-apiserver configured with OIDC flags. kubectl authenticates against the identity provider, then presents the resulting token to kube-apiserver, which validates it and defers to RBAC for access decisions.

The critical configuration choice is using a public OIDC client with PKCE, not a confidential client. Confidential clients require a shared secret, which must be distributed to every machine needing access, undermining its purpose. PKCE mitigates this by ensuring that intercepted authorization codes cannot be redeemed without the original proof key. The client configuration in Keycloak reflects this: client authentication is disabled, PKCE is enforced, and redirect URIs are restricted to loopback addresses. This setup ensures that credentials are ephemeral and tied to individual sessions, not static files.

Deployment involves configuring the identity provider to include group membership in ID tokens and pointing kube-apiserver to the issuer. Kubernetes RBAC binds to usernames and groups asserted by the token, so the identity provider must map group membership to a claim. If the identity provider uses a self-signed certificate, kube-apiserver must be configured to trust it. The result is a system where access control is dynamic, auditable, and aligned with identity management practices, rather than a static credential distribution problem.