Mastering Kubernetes Authentication, Authorization, and Admission Control

Authentication

Kubernetes secures every request to the API server through a three‑step process: authentication, authorization, and admission control. The API server is the sole entry point for all cluster operations.

Token authentication

Clients present a bearer token in the HTTP Authorization header. The token is generated from a secret stored in the cluster and is used by kubectl to prove the identity of the caller.

SSL (certificate) authentication

Both the API server and the client present X.509 certificates signed by a trusted CA. Mutual TLS ensures that the server authenticates the client and vice‑versa, providing encrypted communication.

Service Accounts

Service accounts are Kubernetes resources designed for pod‑to‑API‑server communication. Unlike user accounts, they are namespace‑scoped and automatically mounted as a secret containing a token.

When a pod is created without an explicit serviceAccountName, the default service account of its namespace is assigned.

kubectl create serviceaccount test

kubectl get serviceaccount

kubectl describe serviceaccount test

The generated secret (e.g., test-token-xxxx) holds the token that pods use to authenticate to the API server.

Authorization

After authentication, Kubernetes determines whether the request is allowed. Several authorizers can be enabled; a request is permitted if any authorizer grants access.

Node Authorization

Restricts kubelet access to node‑related resources. Enabled with --authorization-mode=Node,RBAC and the NodeRestriction admission plugin.

ABAC (Attribute‑Based Access Control)

Uses a JSON policy file to define permissions. The API server is started with

--authorization-mode=ABAC --authorization-policy-file=policy.json

. Example policy:

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "alice",
    "namespace": "*",
    "resource": "*",
    "apiGroup": "*"
  }
}

RBAC (Role‑Based Access Control)

RBAC is the default authorizer in recent Kubernetes releases. It defines four resource types:

Role – namespaced permissions

ClusterRole – cluster‑wide permissions

RoleBinding – binds a Role to a user, group, or service account

ClusterRoleBinding – binds a ClusterRole to a subject

Typical commands to inspect RBAC objects:

kubectl get roles --all-namespaces
kubectl get clusterroles
kubectl get rolebindings --all-namespaces
kubectl get clusterrolebindings

System‑defined ClusterRoles (prefixed with system:) provide the baseline permissions for components such as the kubelet.

Webhook Authorization

External HTTPS services can make authorization decisions. The API server is configured with --authorization-webhook-config-file=webhook-config.yaml. See the official documentation for the file format.

Admission Control

Admission controllers are plugins that intercept requests after authorization but before persistence. If any plugin rejects the request, the operation fails.

AlwaysAdmit – allows all requests (default for testing)

AlwaysDeny – blocks all requests (testing)

AlwaysPullImages – forces image pull before container start

DenyEscalatingExec – blocks exec/attach on privileged pods

ServiceAccount – auto‑creates service‑account secrets

SecurityContextDeny – disables securityContext fields

ResourceQuota – enforces namespace resource quotas

LimitRanger – enforces limit ranges on pods/containers

NamespaceLifecycle – prevents creation in non‑existent namespaces and cleans up on deletion

PodSecurityPolicy – validates pod security settings

Recommended admission plugins for Kubernetes ≥1.6:

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

For Kubernetes ≥1.4 the recommended set is slightly smaller:

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota