Authentication & Authorization

TL;DR

• API requests pass through Authentication (401 if fails) → Authorization (403 if fails) → Admission Control
• Kubernetes has no native User object; identity comes from external sources (certificates, OIDC, tokens, webhooks)
• Client certificates use CN field as username, O fields as group memberships
• Authorization modes (Node, RBAC, ABAC, Webhook) are evaluated in order; first match decides
• kubectl auth can-i checks permissions without changing credentials; requires impersonate permission
• 403 = Authentication succeeded but authorization denied; 401 = Authentication failed

Core Concepts

The Request Pipeline

Every API server request passes through three sequential stages:

1. Authentication — “Who is making this request?” Extracts identity (username, groups) from credentials (certificate CN/O, token, OIDC claims, etc.). Failure returns 401.

2. Authorization — “Is this authenticated user allowed to perform this action?” Checks whether the user/groups have permission for the specific verb on the specific resource. Failure returns 403.

3. Admission Control — “Is this object itself valid/safe?” Mutates or rejects the object based on policy (e.g., policy enforcement, image validation, quota enforcement). Failure returns 400 or 422.

Authentication Methods

Kubernetes has no native User management — identity is always delegated to external systems:

Client Certificates — Extracted from the CN and O fields of a client certificate. CN becomes the username; O fields become group memberships. Used in kubeadm’s admin.conf.

Bearer Tokens — A token string sent in the Authorization: Bearer <token> header. May be static (less common) or service account tokens (common).

OIDC (OpenID Connect) — Integrates with an external identity provider (Okta, Azure AD, Google, etc.). Provides SSO and centralized user management; standard for real organizations.

Webhook Token Authentication — API server calls an external service to validate arbitrary token formats.

Client IP — Rarely used; authorizes based on source IP (legacy, not recommended).

Authorization Modes

Configured via the API server’s --authorization-mode flag (comma-separated list, evaluated left-to-right):

Node — Restricts kubelets to resources related to their own node. Only affects kubelet requests.

RBAC (Role-Based Access Control) — Modern default. Uses Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects to define granular permissions.

ABAC (Attribute-Based Access Control) — Legacy. Policy defined in a static JSON file on disk; requires API server restart to change. Rarely used today.

Webhook — Delegates authorization decisions to an external service.

Most production clusters use Node,RBAC — Node mode first (to authorize kubelets), then RBAC for everything else.

User and Group Identity

Kubernetes has no native User resource. User identity is a string extracted from whatever authentication method is in use (certificate CN, token claims, etc.). Groups are lists of strings (organization fields from certs, group claims from OIDC, etc.).

Impersonation

Impersonation allows one user to act as another without switching credentials. Requires explicit impersonate permission on the target user/serviceaccount/groups. Useful for testing whether another user can perform an action:

kubectl auth can-i create pods --as=jane-dev

This permission is powerful and should be tightly restricted.

Configuration and Diagnostics

Viewing Current Identity and Permissions

# View the authentication method in the current context
kubectl config view --minify

# Extract and inspect your client certificate identity
kubectl config view --raw -o jsonpath='{.users[0].user.client-certificate-data}' | \
  base64 -d | openssl x509 -noout -subject -text

# List all permissions available to your current user
kubectl auth can-i --list

# Check a specific action (own permissions)
kubectl auth can-i create deployments

# Check permissions for another user (requires impersonate permission)
kubectl auth can-i create deployments --as=jane-dev -n payments

Testing Authorization Without Changing Credentials

# Test if a user can perform an action (dry run)
kubectl auth can-i <verb> <resource> --as=<username> [-n <namespace>]

# Examples
kubectl auth can-i create pods --as=jane-dev
kubectl auth can-i delete secrets --as=system:serviceaccount:payments:deploy-bot -n payments
kubectl auth can-i get configmaps --as=monitoring-user

Generating Client Certificates for Users

# 1. Generate a CSR (after approval and signing by kubeadm)
openssl genrsa -out jane.key 2048
openssl req -new -key jane.key -out jane.csr \
  -subj "/CN=jane-dev/O=platform-team"

# 2. Submit CSR and wait for approval (see k8s-21 for full workflow)

# 3. Configure kubeconfig with the signed certificate
kubectl config set-credentials jane-dev \
  --client-certificate=jane.crt \
  --client-key=jane.key

kubectl config set-context jane-dev-context \
  --cluster=kubernetes \
  --user=jane-dev

# 4. Switch to this context to test
kubectl config use-context jane-dev-context

Comparison Table

Error	Meaning	Root Cause	Troubleshooting
401 Unauthorized	Authentication failed	Invalid cert, expired token, wrong credentials	Check kubeconfig, verify certificate validity, renew tokens
403 Forbidden	Auth succeeded, but permission denied	Missing RBAC role/binding	Use kubectl auth can-i to check permissions, inspect RoleBindings
400 Bad Request	Admission control rejected	Invalid object, quota exceeded, policy violation	Review admission controller logs, check ResourceQuota, LimitRange

Common Pitfalls

Pitfall — CN vs. O Fields in Client Certificates Misunderstood User bindings are created for the wrong field, causing 403 errors despite RBAC appearing correct.

• Why: CN (/CN=jane-dev) becomes the username; O fields (/O=platform-team) become group memberships. RoleBinding subjects must match the correct field.
• Fix: When creating RoleBindings from certificates, use kind: User, name: jane-dev for the CN field and kind: Group, name: platform-team for O fields.

Pitfall — Confusing 401 and 403 Assuming 403 means authentication failed when it actually means authorization failed.

• Why: 401 = Authentication failed; 403 = Authentication succeeded but authorization denied.
• Fix: 403 means the user is recognized; troubleshoot RBAC roles and bindings, not credentials.

Pitfall — impersonate Permission Too Broadly Granted Granting all developers impersonate permission without restriction.

• Why: impersonate allows acting as any user, serviceaccount, or group. Unrestricted access is dangerous.
• Fix: Scope impersonate permission narrowly (e.g., allow impersonating only specific serviceaccounts, not all users).

Pitfall — Missing RBAC Bindings for New Authentication Methods Configuring OIDC or webhook authentication but forgetting to create corresponding RBAC RoleBindings.

• Why: Authentication extracts identity, but authorization requires explicit permission bindings. A new auth method with no bindings grants zero access.
• Fix: After adding authentication, create RoleBindings binding users/groups to roles.

Interview Questions

Q — Explain the three stages of the API server request pipeline. What HTTP status code indicates failure at each stage?

Q — How does Kubernetes extract identity from client certificates? Which fields become username vs. groups?

Q — Why does Kubernetes have no native User object? How is identity managed?

Q — Compare client certificate, OIDC, and bearer token authentication methods. When would you use each?

Q — What does 403 Forbidden actually tell you? How do you troubleshoot it?

Q — Explain the impersonate permission. Why is it powerful and potentially dangerous?

Q — Design an authentication and authorization scheme for a multi-team cluster where each team should only access their own namespace.

Q — How would a cluster admin grant a developer kubectl auth can-i permission to test other users’ permissions?