Use an OIDC public client (PKCE) for kubectl access — don’t distribute a client secret

# Summary

# How the pieces fit together

# Why use a public client with PKCE, not a confidential client A confidential client issues a client secret. That secret typically gets copied into kubelogin configs and distributed to every machine that needs access. At that point it is a shared static credential. Rotating the secret requires coordinated pushes to all clients.

# Concrete IdP client settings (example for Keycloak)

• Client ID: kubernetes
• Client authentication: Off (public client, no secret issued)
• Standard flow: On
• Require PKCE: On, method S256
• Redirect URIs and Web origins: loopback only (http://127.0.0.1: and http://localhost:)
• Client scopes: openid, profile, email, groups

# Deployment checklist

1. 1Add a groups claim mapper on the IdP so group membership appears in the ID token under the claim name groups. Kubernetes RBAC binds to usernames and groups asserted by the token. Without groups in the token, you'll have to manage access with usernames only.

1. 1Configure kube-apiserver with OIDC flags:

• --oidc-issuer-url=https:// /realms/
• --oidc-client-id=kubernetes
• --oidc-username-claim=preferred_username
• --oidc-groups-claim=groups

If the IdP uses a certificate not signed by a public CA, supply --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt so the API server trusts the issuer's signing keys.

1. 1Install and configure the kubelogin (kubectl oidc-login) exec plugin on clients. The plugin launches the browser login, enforces PKCE, and returns the ID token to kubectl for each API request.

# Practical benefits

• Revocation and role changes become identity operations (modify group membership) rather than chasing files.
• No shared secret sitting on every client to rotate or leak.
• Authentication becomes consistent with cloud IAM and SSO practices while remaining usable for on-prem clusters.

# Common pitfalls

• Forgetting to add groups to the ID token means RBAC can't use group bindings.
• Not supplying oidc-ca-file when using a private CA causes TLS verification errors when the API server tries to fetch the issuer's signing keys.
• Using confidential clients forces secret distribution and undermines security gains.