Skip to main content

More Info:

Client certificates are hard to revoke and manage, making them weak for user authentication. Use OIDC instead.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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-key versus OIDC (auth-provider: oidc or exec plugins that obtain OIDC tokens).
  2. Inspect API server authentication configuration
    • On every control plane node:
    • Confirm whether --client-ca-file is configured (enables client cert auth) and whether OIDC flags (--oidc-issuer-url, --oidc-client-id, etc.) are already present.
  3. 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.
  4. 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-key and configure OIDC instead, per your IdP’s guidance (e.g. auth-provider: oidc or an exec plugin).
    • Keep client certificate access in place during a transition window so users can switch without lockout.
  5. 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.yaml and, following your migration plan:
      • Ensure any --client-ca-file referenced 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-file to 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.
    • Be aware: saving this file will cause the kube-apiserver static pod to be restarted on that control plane node.
  6. 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.
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.
What output indicates a problem
  • --client-ca-file is 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-data and
  • 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.
This script only reports state; migration away from client certificates to OIDC must be planned and executed manually.