Authentication is the first gate in the API server pipeline: "Who are you?" Kubernetes doesn't manage user accounts itself — it delegates authentication to external systems (certificates, tokens, OIDC providers). Understanding the authentication methods is critical for CKS and for securing production clusters.

1. Two Types of Identity

Kubernetes distinguishes between two kinds of identities:

The Authentication Flow

The API server runs multiple authenticators. Each request is tried against all configured plugins. The first one that succeeds establishes the identity. If all fail → 401 Unauthorized.

2. X.509 Client Certificates

The most common authentication for cluster components (kubelet, scheduler, controller-manager) and kubeadm-created admin users. The API server trusts any certificate signed by its configured CA.

How It Works

1. Client presents a TLS client certificate during the HTTPS handshake
2. API server validates the cert against its --client-ca-file (the cluster CA)
3. Username is extracted from the certificate's Common Name (CN)
4. Groups are extracted from the certificate's Organization (O) fields

# Certificate with CN=jane, O=developers, O=admins
# → Authenticated as user "jane" with groups ["developers", "admins"]

Creating a User Certificate (CKA Exam Pattern)

# 1. Generate private key:
openssl genrsa -out jane.key 2048

# 2. Create Certificate Signing Request (CSR):
openssl req -new -key jane.key -out jane.csr \
  -subj "/CN=jane/O=developers"
#         ↑ username    ↑ group

# 3. Submit CSR to Kubernetes for signing:
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: jane-csr
spec:
  request: $(cat jane.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kube-apiserver-client
  usages: ["client auth"]
EOF

# 4. Approve the CSR:
kubectl certificate approve jane-csr

# 5. Get the signed certificate:
kubectl get csr jane-csr -o jsonpath='{.status.certificate}' | base64 -d > jane.crt

# 6. Add to kubeconfig:
kubectl config set-credentials jane \
  --client-certificate=jane.crt \
  --client-key=jane.key
kubectl config set-context jane-ctx \
  --cluster=kubernetes --user=jane

3. OIDC (OpenID Connect)

The recommended method for human users in production. Integrates with identity providers (Google, Azure AD, Okta, Keycloak, Dex) for SSO with centralized user management.

How It Works

1. User authenticates with the OIDC provider (login page, MFA)
2. Provider returns an ID token (JWT) containing user claims
3. kubectl sends the JWT as a bearer token to the API server
4. API server validates the JWT signature against the provider's public keys
5. Username/groups extracted from configured JWT claims

# API server configuration for OIDC:
kube-apiserver \
  --oidc-issuer-url=https://accounts.google.com \
  --oidc-client-id=my-k8s-cluster \
  --oidc-username-claim=email \
  --oidc-groups-claim=groups \
  --oidc-username-prefix="oidc:" \
  --oidc-groups-prefix="oidc:"

OIDC vs Certificates

4. ServiceAccount Tokens

ServiceAccounts are for Pods and automated systems — not humans. Every namespace has a default ServiceAccount. Pods use SA tokens to authenticate with the API server.

Modern Bound Tokens (K8s 1.22+)

# Automatically projected into every Pod:
/var/run/secrets/kubernetes.io/serviceaccount/token

# This is a short-lived JWT (bound token):
# - Expires after 1 hour (auto-rotated by kubelet)
# - Bound to the specific Pod (invalidated on Pod deletion)
# - Audience-bound (valid only for the API server)

# Decoded token payload:
{
  "iss": "https://kubernetes.default.svc",
  "sub": "system:serviceaccount:default:my-app-sa",
  "aud": ["https://kubernetes.default.svc"],
  "exp": 1705334400,
  "iat": 1705330800,
  "kubernetes.io": {
    "namespace": "default",
    "pod": {"name": "web-abc", "uid": "..."},
    "serviceaccount": {"name": "my-app-sa", "uid": "..."}
  }
}

Creating Long-Lived Tokens (When Needed)

# For external systems that need a static token (CI/CD, monitoring):
apiVersion: v1
kind: Secret
metadata:
  name: ci-token
  annotations:
    kubernetes.io/service-account.name: ci-sa
type: kubernetes.io/service-account-token
# Controller generates a non-expiring token in this Secret

# Or create a token with specific expiry:
kubectl create token ci-sa --duration=8760h   # 1 year

5. Other Authentication Methods

Bootstrap Tokens

# Used during kubeadm join — short-lived tokens for node registration:
kubeadm token create --print-join-command
# Token format: abcdef.0123456789abcdef (6 chars.16 chars)
# Stored as Secrets in kube-system namespace
# Default TTL: 24 hours — expire after cluster bootstrap

Webhook Token Authentication

# Delegates authentication to an external service:
kube-apiserver --authentication-token-webhook-config-file=/etc/k8s/webhook-config.yaml
# API server sends the bearer token to your webhook
# Webhook responds with: authenticated=true, user=..., groups=[...]
# Use case: custom auth systems, legacy token validation

Static Token File (Avoid in Production)

# API server reads tokens from a CSV file:
# kube-apiserver --token-auth-file=/etc/k8s/tokens.csv
# Format: token,user,uid,"group1,group2"
# ⚠️ Not recommended: no expiry, no revocation, requires API server restart to change

Anonymous Authentication

# If no authenticator matches → request is anonymous:
# user: system:anonymous
# groups: [system:unauthenticated]
# Some paths allow anonymous (healthz, readyz)
# Disable for non-public endpoints: --anonymous-auth=false

6. What Each Component Uses

Summary