Kubernetes Authentication & Authorization

The two-gate security model of the Kubernetes API server: every request must pass authentication (who are you?) and authorization (what can you do?) before a resource is accessed. Core to the ~25% Cluster Architecture CKA domain. Source: CKA Day 22 Source: CKA Day 23

The Request Pipeline

When kubectl (or any client) sends a request to the API server, it flows through a strict pipeline:

Client Request → TLS Termination → Authentication → Authorization → Admission Control → Resource

1. TLS Termination — The API server presents its server certificate. The client verifies it against the cluster CA.
2. Authentication — The API server extracts credentials from the request (client cert, bearer token, or basic auth) and verifies identity using the configured authentication plugin.
3. Authorization — The authenticated UserInfo (username, groups, UID) is passed to the authorization chain. The first module that returns an allow/deny decision wins.
4. Admission Control — Optional mutating/validating webhooks that enforce policy (e.g., PodSecurity, ResourceQuota).

Authentication (AuthN)

Kubernetes does not have a built-in user database. Instead, it delegates identity verification to pluggable mechanisms configured on the API server.

Authentication Methods

Method	CKA Relevance	How It Works
X.509 Client Certificates	High	Client presents a certificate signed by the cluster CA. API server extracts the Common Name as username and Organization as group. Used by kubeadm and most admin tools.
Bearer Tokens	High	Static tokens in files, service account tokens (auto-mounted into Pods), or OIDC tokens from identity providers (e.g., Azure AD, Okta).
Webhook Token Authentication	Medium	API server POSTs the token to an external service for verification. Enables SSO and custom identity providers.
Basic Auth	Deprecated	Username/password in a CSV file. Disabled by default and removed in modern distributions.
Anonymous Auth	Low	Unauthenticated requests are mapped to system:anonymous user and system:unauthenticated group. Disabled in production.

Service Account Authentication

Every Namespace has a default ServiceAccount. When a Pod is created, Kubernetes automatically:

1. Creates a ServiceAccount token (JWT) and stores it as a Secret
2. Mounts that Secret as a volume at /var/run/secrets/kubernetes.io/serviceaccount
3. Sets environment variables KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT

Inside the Pod, applications use this token to call the API server. The token is bound to the ServiceAccount’s identity and subject to its RBAC permissions. Source: CKA Day 22

Authorization (AuthZ)

After authentication, the request enters the authorization chain. The API server checks modules in the order specified by --authorization-mode:

--authorization-mode=Node,RBAC  # default in modern clusters

Authorization Modules

Module	Scope	CKA Relevance
Node	Node-local	Grants kubelet read/write access only to resources bound to its own node. Enabled by default.
ABAC	Cluster-wide	Legacy file-based policy. Evaluates attributes of user, resource, and environment. Replaced by RBAC.
RBAC	Namespace + Cluster	The modern standard. Uses Kubernetes API objects (Role, ClusterRole, RoleBinding, ClusterRoleBinding).
Webhook	Cluster-wide	Delegates to an external HTTP service (e.g., OPA, AWS IAM). Useful for multi-cluster policy.

RBAC Decision Flow

RBAC evaluates a request by asking three questions:

1. Who? — The subject (User, Group, or ServiceAccount) referenced in the Binding
2. Can do what? — The verb (get, list, watch, create, update, patch, delete, deletecollection) on the resource
3. On what? — The resource name, namespace (for Roles), or cluster scope (for ClusterRoles)

If any Role or ClusterRole bound to the subject contains a matching rule, the request is allowed. There is no deny rule in RBAC — lack of permission equals denial. Source: CKA Day 22

Kubeconfig: The Client Credential Bundle

The kubeconfig file (~/.kube/config by default) is the client-side map that tells kubectl which cluster to talk to and how to authenticate. It decouples cluster endpoint configuration from user credentials. See the dedicated Kubernetes Kubeconfig deep-dive for full YAML anatomy and command reference. Source: CKA Day 22

Direct REST API Access

kubectl is a sophisticated REST client. The API server exposes all resources under /api/v1/ (core) and /apis/<group>/v1/ (named groups). You can call these endpoints directly with curl using a client certificate for mutual TLS:

curl https://<control-plane-ip>:6443/api/v1/namespaces/default/pods \
  --cacert /path/to/ca.crt \
  --cert /path/to/client.crt \
  --key /path/to/client.key

This returns raw JSON from the API server. The same TLS and RBAC rules apply regardless of whether the client is kubectl, curl, or a custom application. Source: CKA Day 23

CKA Exam Patterns

• Switch Contexts: kubectl config use-context <context-name> is the first command in many exam tasks
• Impersonate: kubectl auth can-i <verb> <resource> --as <user> tests permissions without logging in as that user
• Debug Forbidden: kubectl describe rolebinding and kubectl describe clusterrolebinding reveal which subjects have which roles
• ServiceAccount Secrets: Since 1.24, ServiceAccount tokens are no longer auto-generated as Secrets unless explicitly requested or projected via TokenRequest API
• Count Objects: kubectl get roles --no-headers -A | wc -l counts cluster-wide roles without header noise

Related Pages

• Kubernetes RBAC — Deep dive into Roles, ClusterRoles, Bindings, and YAML patterns
• Kubernetes Kubeconfig — clusters, users, contexts, and imperative kubectl config commands
• Kubernetes Architecture — API server request flow and component security
• Kubernetes Namespaces — Namespace-scoped vs cluster-scoped RBAC boundaries
• TLS Fundamentals — X.509 certificates underpinning Kubernetes client certificate authentication
• CKA Certification — Exam structure with ~25% Cluster Architecture domain

---

Tags: kubernetes security authentication authorization rbac cka api-server