For people who use the API directly, use an external identity provider through OpenID Connect. Client certificates, static token files and service account tokens each have properties that make them a poor fit for human users, according to the Kubernetes hardening guide.
General rule
The guide says to enable as few authentication mechanisms as possible, to simplify user management and limit lingering access. Kubernetes has no built-in user database, so to audit who has access you must review credentials from every configured source. Fewer sources means a shorter review.
Client certificates
Meant mainly for system components, such as the kubelet talking to the API server. Limits the guide lists:
- A certificate cannot be revoked individually. A compromised one stays valid until it expires, so lifetimes should be short. Invalidating one means re-keying the CA, which risks availability.
- There is no permanent record of issued certificates unless you keep one.
- Private keys cannot be password protected, so anyone who can read the file can use it.
- Group memberships sit in the certificate and cannot change during its life.
Static token file
Not recommended for production. Credentials are in clear text on control plane disks, changing one requires an API server restart, users have no rotation mechanism, and there is no lockout against brute force.
Service account tokens
Legacy Secret-based tokens cannot expire and remain valid until the account is deleted. They are visible to anyone who can read Secrets in the namespace. Short-lived tokens from the TokenRequest API are better for services, but the guide notes there is no revocation method, and distributing them securely to users is hard. Both are for workloads, not people. See Kubernetes service account tokens explained.
OpenID Connect
OIDC integrates an external identity provider, so joiners, leavers, MFA and group changes are managed in one place. The guide's cautions:
- Software in the cluster that supports OIDC runs with high privileges, so isolate it from general workloads.
- Some managed services limit which providers you can use.
- Keep OIDC token lifetimes short.
Decision guide
- Engineers and admins: OIDC with your identity provider
- Cluster components: Client certificates with short lifetimes
- Pods calling the API: Projected service account tokens
- Production anything: Not static token files
Also review bindings to system:unauthenticated and remove them where possible, as the RBAC guidance advises.
Reviewing what you have today
List the authentication sources your API server accepts. Then list the credentials from each: certificates issued by your CA, entries in any token file, service account tokens, and OIDC groups. For each source, name an owner and an expiry practice. Drop any source nobody can explain.
The point of the review is to shorten the list of places where access can linger after someone leaves.
Quick check
Can I revoke one leaked client certificate?
Not individually, per the hardening guide. Short lifetimes limit the exposure, and a full fix means re-keying the CA.
Do managed clusters let me pick any OIDC provider?
Not always. Check your provider's limits.
Sources
Last reviewed: 19 October 2026.
