Kubernetes Client Certificate Access

Kubernetes Client Certificate Access is the authentication approach in which a client proves its identity to the API server by presenting an X.509 certificate signed by a certificate authority the server trusts, with the certificate's subject fields directly determining the username and group memberships used for subsequent authorization. It is the mechanism Kubernetes itself relies on internally for control-plane components and kubelets, and it is also available for human and external client access, making it one of the oldest and most foundational identity mechanisms in the platform.

How Certificate Authentication Works

Establishing Trust

The API server is configured with one or more CA certificates via --client-ca-file. Any TLS client certificate presented during the mutual TLS handshake that chains up to one of these CAs is accepted as authenticated, with no further external validation performed — the API server does not check certificate revocation lists by default, so trust is entirely a function of who was able to obtain a certificate signed by the configured CA.

Extracting Identity from the Certificate

The certificate's Subject Common Name (CN) becomes the username, and each Subject Organization (O) entry becomes a group the identity belongs to. A certificate issued with CN=alice, O=platform-team, O=on-call authenticates as user alice in groups platform-team and on-call simultaneously.

openssl req -new -key alice.key -out alice.csr \
  -subj "/CN=alice/O=platform-team"

Issuing Client Certificates

Using the Kubernetes CertificateSigningRequest API

Kubernetes provides a built-in CertificateSigningRequest object that lets a client submit a CSR to the cluster for approval and signing by the cluster's own CA, avoiding the need for a separate external PKI for basic use cases.

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: alice-access
spec:
  request: <base64-encoded CSR>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

An administrator with the appropriate permissions approves the request, after which the signed certificate can be retrieved from the CSR object's status.

kubectl certificate approve alice-access
kubectl get csr alice-access -o jsonpath='{.status.certificate}' | base64 -d > alice.crt

External PKI Integration

Larger organizations typically issue client certificates from an internal enterprise CA rather than the cluster's own signer, which centralizes certificate lifecycle management across many clusters and integrates with existing PKI tooling for issuance and inventory tracking.

Operational Limitations

No Native Revocation

Because the API server does not consult a certificate revocation list or an OCSP responder by default, a compromised or improperly retained certificate remains valid until it expires, regardless of any organizational decision to revoke the underlying access. This is the most significant operational weakness of client certificate authentication in Kubernetes.

Compensating for the Lack of Revocation

Common mitigations include issuing certificates with short validity periods so that exposure windows are naturally bounded, and, in more severe cases, rotating the entire client CA — which invalidates every certificate signed by the old CA at once but also requires re-issuing certificates for every legitimate user and component.

Group Membership Is Fixed at Issuance

Because groups are embedded in the certificate itself, a user's group membership cannot be changed without issuing them a new certificate, unlike OIDC-based groups which are recomputed by the identity provider on every token issuance.

Where Certificate Access Is Used in Practice

Control Plane Components

The kubelet, kube-scheduler, and kube-controller-manager each authenticate to the API server using dedicated client certificates provisioned during cluster bootstrap, often through the kubelet's TLS bootstrapping process, which requests and automatically rotates its own serving and client certificates over time.

Break-Glass Administrative Access

Some clusters reserve certificate-based authentication specifically for emergency administrative access, since it does not depend on an external identity provider being reachable, making it a viable fallback when OIDC or webhook authentication infrastructure is unavailable.

Security Considerations

Protecting Private Keys

Because the certificate's private key is the only secret material involved, any exposure of that key grants full impersonation of the associated identity until the certificate expires or the CA is rotated; private keys should never be transmitted over insecure channels or stored unencrypted on shared systems.

Auditing Certificate Issuance

Every CertificateSigningRequest approved through the cluster API is recorded in the audit log and can be reviewed with kubectl get csr, giving administrators a record of every identity that has ever been granted certificate-based access through the cluster's own signer.