A post published on the CNCF blog recommends treating access control for Kubernetes clusters as part of the basic setup checklist, alongside networking and storage—especially in self-hosted environments, which generally do not provide ready-made IAM or SSO integration as managed Kubernetes services do. The central idea is to use an OIDC-compliant identity provider, such as Keycloak, while registering the client as a public client that uses PKCE, rather than as a confidential client carrying a shared secret.
In many local clusters, access relies on a static client certificate or a long-lived token issued once. These credentials remain valid even after an employee leaves, changes roles, or loses the device containing them. Revoking access also requires finding every copy of the certificate or token file, a process whose completeness is difficult to guarantee when devices and users multiply. As the number of people and the range of permission levels grow, distributing and managing files becomes an ongoing operational task.
What Changes with OIDC?
Instead of tying authorization to a certificate file, it becomes tied to the user’s account and membership in the identity provider’s groups. The integration consists of three interconnected parties: the kubectl tool with the kubelogin or kubectl oidc-login plugin, the identity provider that authenticates the user and issues the ID token, and the kube-apiserver, which validates the token and extracts the username and groups, then leaves Kubernetes RBAC to determine which operations are permitted.
kubectl does not contact the API server first to begin the login. The exec-credential plugin launches a browser-based login with the identity provider, then returns the ID token to kubectl so it can be sent as a bearer-token credential. The API server validates the token using the identity provider’s public signing keys. According to the article, the server does not need a continuous connection to the identity provider, apart from fetching those keys when necessary.
Why Should the Client Be Public?
A confidential client issues a secret that is added to the kubelogin plugin’s configuration and distributed to every device that needs access. The article argues that a secret that must be distributed to all clients is no longer truly secret, but rather a shared static credential that is difficult to rotate. For command-line tools and native applications, the more appropriate choice is a public client without a secret, with PKCE, or Proof Key for Code Exchange, enabled.
The client generates a random value locally and sends a hash of it in the initial login request, then proves that it possesses the original value when exchanging the authorization code for an access token. Therefore, someone who intercepts only the authorization code cannot complete the process. The Keycloak settings presented in the article recommend disabling client authentication, enabling the standard flow, disabling direct access grants, and enforcing PKCE using S256, while restricting redirect URIs and web origins to loopback addresses such as 127.0.0.1 and localhost.
Basic Setup Steps
- Add a group-membership mapper to the client scope in Keycloak so that a claim named groups appears in the ID token.
- Configure kube-apiserver using flags such as oidc-issuer-url, oidc-client-id, oidc-username-claim, and oidc-groups-claim.
- Add oidc-ca-file if the identity provider uses a certificate that is not signed by a publicly trusted authority, so that the API server can verify the TLS connection and retrieve the signing keys.
- Modify kubeconfig to use an exec-credential entry through kubectl oidc-login instead of embedding certificates or static tokens, without adding a secret field.
- Map identity-provider groups to Kubernetes RBAC roles, such as mapping a platform-viewer group to the view role.
Practical Impact and Limitations
After this integration, access changes are made within the identity provider: adding a user to or removing them from a group, rather than modifying the cluster or redistributing kubeconfig. The next token issued to the user contains the new group membership, so the RBAC rule associated with it is applied. The article explains that the first login opens the browser, while kubelogin reuses the token cached locally until it expires, then uses the refresh token without another browser round trip. The actual identity and groups can be verified with the kubectl auth whoami command.
This does not mean that the integration has no operational requirements. The group claim must be configured precisely, the identity provider’s certificate must be verified, redirect URIs must be restricted, and RBAC roles must be checked to ensure that they reflect the required permissions. The article also does not provide independent measurements of setup time or operating cost; it estimates that preparation may be completed within a single working period, rather than through a full platform migration.
The main security and administrative benefit is that Kubernetes logs become linked to the actual user identity. Logs that rely on a shared account such as cluster-admin do not distinguish between request initiators, whereas every request issued through OIDC carries the username and associated groups. This is an editorial reading based on the article’s details: the improvement is not only in the login method, but also in the ability to attribute actions to their owners, while making permission granting and revocation a centralized identity operation instead of a search for distributed credential files.