Interactive Explainer

Relevant for:JuniorMid-levelSeniorStaff

Why this matters at your level

Junior

Know the difference between 401 (authn fail) and 403 (authz fail). Know that users do not exist as objects in K8s. Understand what a kubeconfig contains.

Mid-level

Set up OIDC auth with Dex and an external IdP. Configure cert rotation automation. Know kubeadm certs renew all and which components need restart afterward.

Senior

Design auth strategy for a multi-team cluster: OIDC for humans, bound SA tokens for workloads, break-glass certs stored in a vault. Implement cert rotation as a CronJob. Audit all ServiceAccounts for long-lived tokens.

Staff

Own authentication posture across 10+ clusters. Define cert lifecycle management policies. Lead migration from static kubeconfigs to OIDC. Define break-glass and recovery runbooks. Know how to recover a cluster from complete cert expiry with zero data loss.

Kubernetes Authentication

How the API server verifies identity -- certificates, tokens, OIDC, and what happens when they expire.

~4 min read

Be the first to complete!

LIVEControl Plane Lockout -- Production Cluster -- Expired Certificates

Breaking News

T+0

Engineer runs kubectl get pods -- Error: certificate has expired

CRITICAL

T+5m

Team checks all nodes -- control plane shows Running but API unreachable

WARNING

T+30m

kubeadm certs check-expiration: all 6 certs expired yesterday

CRITICAL

T+2h

kubeadm certs renew all completes -- controller-manager still using stale in-memory cert

WARNING

T+3h

Static pod manifests touched -- all control-plane pods restart -- kubectl works again

—Complete API lockout

—Certs that expired simultaneously

—Default kubeadm cert lifetime

—Cost of cert renewal automation

The question this raises

How does Kubernetes authenticate every request, what certificates does it rely on, and how do you recover from a complete certificate expiry without losing the cluster?

Test your assumption first

An engineer runs kubectl get pods and gets: "error: You must be logged in to the server (Unauthorized)". The cluster nodes are reachable and other teams report normal operation. What is the most likely cause?

Lesson outline

What authentication does -- and does not do

Authentication answers one question: who are you?

It does NOT answer "what can you do?" -- that is authorization (RBAC). Every request to the Kubernetes API server must pass authn first. If authn fails, the server returns 401. If it passes but the action is unauthorized, it returns 403. These two steps are always separate.

User identity vs Service Account identity

Use for: Humans and external tools use certificates or OIDC tokens. Pods use ServiceAccount tokens automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. These are two completely separate authentication pipelines.

Kubernetes has no User object

Use for: kubectl get users returns "No resources found." Users exist only as strings inside certificates (CN field) or JWT claims. This surprises everyone the first time -- you cannot list users, you can only create RoleBindings that reference username strings.

The six authentication methods


kubectl / curl
     |
     | HTTPS request
     v
+-------------------+
|  API Server       |
|  Auth Chain       |
+-------------------+
     |
     +---> [1] Client Certificate  -- CN=system:admin, O=system:masters
     |          (kubeconfig)
     |
     +---> [2] Bearer Token       -- ServiceAccount JWT or static token file
     |          (Authorization: Bearer <token>)
     |
     +---> [3] OIDC Token         -- Dex / Okta / Google JWT
     |          (--oidc-issuer-url, --oidc-client-id flags on API server)
     |
     +---> [4] Webhook Token Auth -- calls external HTTP endpoint
     |          (enterprise SSO bridge)
     |
     +---> [5] Bootstrap Token    -- kubeadm join only, short-lived
     |
     +---> [6] Anonymous          -- disabled in hardened clusters
     |
     v
Identity: username + groups
     |
     v
Authorization (RBAC)

How this concept changes your thinking

Situation

Before

After

Service Account tokens in Kubernetes < 1.21

“Long-lived tokens with no expiry -- leaked token = permanent access until SA deleted”

“Bound Service Account tokens (1.21+): audience-bound, time-limited, pod-bound -- invalid the moment the pod dies”

OIDC vs cert-based human auth

“Each engineer gets a kubeconfig with a personal cert -- no central revocation, certs last 1 year”

“OIDC via Dex + corporate IdP -- revoke from Okta, access gone instantly, 1-hour token TTL”

How certificate auth works end-to-end

What happens on every kubectl command

→

kubectl reads kubeconfig -- finds cluster CA cert, client cert, client key

→

TLS handshake: API server presents its serving cert (signed by cluster CA), kubectl verifies it

→

kubectl presents its client cert -- API server verifies it against cluster CA

→

API server extracts CN (username) and O (groups) from the client cert Subject field

→

Username + groups passed to RBAC authorizer -- can this identity perform this verb on this resource?

Request proceeds or returns 403

kubectl reads kubeconfig -- finds cluster CA cert, client cert, client key

TLS handshake: API server presents its serving cert (signed by cluster CA), kubectl verifies it

kubectl presents its client cert -- API server verifies it against cluster CA

API server extracts CN (username) and O (groups) from the client cert Subject field

Username + groups passed to RBAC authorizer -- can this identity perform this verb on this resource?

Request proceeds or returns 403

CN=system:masters is God mode

Any certificate with O=system:masters group bypasses RBAC entirely -- hardcoded superuser. This is how break-glass certs work, but also how attackers with CA access own your cluster forever. Guard your cluster CA private key like the root password.

kubeconfig.yaml

1# Typical kubeconfig structure
2apiVersion: v1
3kind: Config
4clusters:
5- cluster:
6    certificate-authority-data: <base64 cluster CA>
7    server: https://api.cluster.example.com:6443
8  name: production
9users:
10- name: sre-team
11  user:
12    client-certificate-data: <base64 client cert>  # CN=alice, O=sre-team
13    client-key-data: <base64 client key>
14contexts:
15- context:
16    cluster: production
17    user: sre-team
18    namespace: default
19  name: production-sre

kubectl

1# Check when your kubeadm certs expire
2kubeadm certs check-expiration
3# CERTIFICATE                EXPIRES                  RESIDUAL TIME
4# admin.conf                 Nov 23, 2025 14:32 UTC   364d
5# apiserver                  Nov 23, 2025 14:32 UTC   364d
6 
7# Renew ALL certs together (on control-plane node)
8kubeadm certs renew all
9 
10# Copy new admin kubeconfig to your ~/.kube/config
11cp /etc/kubernetes/admin.conf ~/.kube/config
12 
13# Restart static control-plane pods to pick up new certs
14# (they don't watch the filesystem -- touch forces kubelet restart)
15touch /etc/kubernetes/manifests/kube-apiserver.yaml
16touch /etc/kubernetes/manifests/kube-controller-manager.yaml
17touch /etc/kubernetes/manifests/kube-scheduler.yaml
18 
19# Create a short-lived ServiceAccount token (K8s 1.24+)
20kubectl create token my-sa --duration=8h --audience=my-service
21 
22# Inspect a ServiceAccount token's claims
23kubectl create token default | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

What breaks in production

Blast radius when authentication breaks

All kubectl access blocked — Every human operator loses access -- you cannot even run kubectl get nodes
CI/CD pipelines fail — Automated deployments stop -- ServiceAccount tokens expire or OIDC provider unreachable
kube-controller-manager cannot authenticate — No new ReplicaSets reconciled -- Deployments frozen, HPA cannot scale
kubelet-to-API auth breaks — Nodes go NotReady -- kubelet cannot report status or pull secrets for new pods
Metrics server / Prometheus fail — Monitoring goes dark -- cluster appears healthy but is actually inaccessible

Partial cert renewal -- leaves components using stale certs

Bug

# WRONG: Only renewing the apiserver cert
kubeadm certs renew apiserver

# Restarting only the API server
systemctl restart kube-apiserver

# Result: kube-controller-manager still has old cert in memory
# Error: "TLS handshake error... certificate has expired"
# Controller manager cannot authenticate to API server

Fix

# RIGHT: Renew ALL certs together
kubeadm certs renew all

# Distribute new kubeconfig to all operators
cp /etc/kubernetes/admin.conf ~/.kube/config

# Restart ALL control plane static pod components
touch /etc/kubernetes/manifests/kube-apiserver.yaml
touch /etc/kubernetes/manifests/kube-controller-manager.yaml
touch /etc/kubernetes/manifests/kube-scheduler.yaml

# Verify renewal succeeded
kubeadm certs check-expiration

kubeadm certs renew all renews all 6 certs atomically. Static pod components hold the old cert in memory -- they must be restarted by touching the manifest file. kubelet watches the /etc/kubernetes/manifests directory and immediately restarts the pod when the file modification time changes.

Decision guide: which auth method to use

Is the requester a Pod or workload running inside the cluster?

YesUse ServiceAccount with bound tokens (auto-mounted) -- set automountServiceAccountToken: false on pods that do not need API access

NoDoes your organization have an IdP (Okta, Azure AD, Google Workspace)?

Does your organization have an IdP (Okta, Azure AD, Google Workspace)?

YesConfigure OIDC authentication (Dex or direct OIDC) -- central revocation, short-lived tokens, no cert rotation headache

NoUse client certificates with a strict rotation policy (CronJob) and store break-glass kubeconfig in an offline vault

Auth method comparison

Method	Lifetime	Revocation	Best for	Risk
Client Certificate	1 year (kubeadm default)	No native revocation -- CRL not supported	Break-glass / bootstrap only	Leaked cert = permanent access until expiry
ServiceAccount JWT (bound)	Minutes to hours (configurable)	Instant -- pod deletion invalids token	Pod-to-API access	Low -- audience + time bound
OIDC (Dex/Okta)	1 hour typical	Instant -- revoke in IdP	Human users in orgs with IdP	Requires OIDC provider availability
Webhook Token	Provider-dependent	Real-time via webhook	Enterprise SSO bridge	Adds external dependency to auth path
Static token file	Never expires	Requires API server restart	Development only -- NEVER production	Tokens in plaintext on disk forever

Exam Answer vs. Production Reality

1 / 2

How Kubernetes authenticates users

📖 What the exam expects

Kubernetes supports multiple authentication methods: client certificates, bearer tokens, OIDC, and webhook token authentication. The API server tries each configured method in order and accepts the first successful one.

Toggle between what certifications teach and what production actually requires

How this might come up in interviews

Asked in security-focused and platform engineering interviews. Senior roles always include a scenario about cert expiry or a user who can no longer access the cluster.

Common questions:

How does the API server know who you are when you run kubectl?
What happens when a ServiceAccount token expires?
How would you rotate all cluster certificates without downtime?
How do you revoke access for an engineer who left the company?
What is the difference between a user certificate and a ServiceAccount token?

Strong answer: Immediately mentions O=system:masters and its danger, knows kubeadm cert renewal procedure, advocates for OIDC over per-user certs, has a break-glass story from experience.

Red flags: Confusing authentication with authorization, thinking kubectl get users works, not knowing cert expiry is a real operational concern, claiming static tokens are fine for production.

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

RBAC & Service Accounts: Identity and Authorization in Kubernetes

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning

RBAC & Service Accounts: Identity and Authorization in Kubernetes

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord

Kubernetes Authentication

What authentication does -- and does not do

The six authentication methods

How certificate auth works end-to-end

What breaks in production

Decision guide: which auth method to use

Auth method comparison

Exam Answer vs. Production Reality

Discussion

In-app Q&A

Kubernetes Authentication

What authentication does -- and does not do

The six authentication methods

How certificate auth works end-to-end

What breaks in production

Decision guide: which auth method to use

Auth method comparison

Exam Answer vs. Production Reality

Discussion

In-app Q&A