More Info:
Client certificates are hard to revoke and manage, making them weak for user authentication. Use OIDC instead.Risk Level
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify how users currently authenticate
- On any machine with access to kubeconfig files (e.g. admin workstation, bastion):
- Review the output to determine which user contexts use
client-certificate/client-keyversus OIDC (auth-provider: oidcorexecplugins that obtain OIDC tokens).
- On any machine with access to kubeconfig files (e.g. admin workstation, bastion):
-
Inspect API server authentication configuration
- On every control plane node:
- Confirm whether
--client-ca-fileis configured (enables client cert auth) and whether OIDC flags (--oidc-issuer-url,--oidc-client-id, etc.) are already present.
- On every control plane node:
-
Determine which client certificate subjects correspond to human users
- On any machine that has user client certificates (often where kubeconfigs are stored):
- For each certificate found in kubeconfigs used by people (not components like kubelets/controllers), record the Subject (CN/O) and map them to real users and groups in your identity system.
- On any machine that has user client certificates (often where kubeconfigs are stored):
-
Plan and, if appropriate, implement migration of human users to OIDC
- Work with your identity provider team to either confirm an existing OIDC integration or define: issuer URL, client ID, redirect URI, groups/username claims.
- Update user kubeconfigs (on user machines) to remove
client-certificate/client-keyand configure OIDC instead, per your IdP’s guidance (e.g.auth-provider: oidcor anexecplugin). - Keep client certificate access in place during a transition window so users can switch without lockout.
-
Restrict or disable client certificate authentication for users (post‑migration)
- On every control plane node, before changing anything, back up the manifest:
- Edit
/etc/kubernetes/manifests/kube-apiserver.yamland, following your migration plan:- Ensure any
--client-ca-filereferenced is only used for non‑user components (e.g. kubelet, front-proxy) and that certificates issued for human users are no longer trusted by that CA; or - Point
--client-ca-fileto a CA that signs only component certs, not human user certs; or, if you have an alternative authentication mechanism for all access, remove--client-ca-file.
- Ensure any
- Be aware: saving this file will cause the kube-apiserver static pod to be restarted on that control plane node.
- On every control plane node, before changing anything, back up the manifest:
-
Verify that human user access no longer depends on client certificates
- On any machine with user kubeconfigs, for a migrated user:
- Attempt the same with a kubeconfig that previously used a client certificate for that user but no longer has OIDC configured; it should now fail.
- On every control plane node, confirm the running apiserver has the intended flags:
- Confirm that only non‑user components (e.g. kubelets, front-proxy) use client certificate authentication and that human users authenticate via OIDC.
- On any machine with user kubeconfigs, for a migrated user:
Using kubectl
Using kubectl
kubectl cannot be used to change client certificate authentication for users because this configuration lives in the kube-apiserver static pod manifest on each control plane node at
/etc/kubernetes/manifests/kube-apiserver.yaml. To review and adjust this setting, follow the guidance in the Manual Steps section on the control plane nodes directly.Automation
Automation
--client-ca-fileis present in the kube-apiserver command line and- One or more kubeconfigs used by human users (for example, developer/admin configs stored in Secrets/ConfigMaps or known off-cluster files) contain
client-certificate-dataand - The kube-apiserver command line does not show OIDC flags (
--oidc-issuer-url,--oidc-client-id, etc.), or you know the listed users in RoleBindings/ClusterRoleBindings are authenticating via client certificates instead of OIDC.

