Mastering Kubernetes Security: Authentication, Authorization, and Admission Control Explained

Kubernetes Security Mechanisms

Mechanism Overview

Kubernetes, as a distributed cluster management tool, must ensure the security of the cluster. The API Server acts as the mediator for component communication and the entry point for external control, so Kubernetes security mechanisms are fundamentally designed around protecting the API Server.

When kubectl requests resources from the API Server, it must pass three gates: Authentication , Authorization , and Admission Control . Only after passing all three can resources be created in the cluster.

Authentication (Authentication)

Authentication verifies the identity of the client. It is the first line of defense and is responsible for confirming the requester's identity.

Three Authentication Methods

HTTP Token Authentication : Uses a long, unique token string stored in a file accessible by the API Server. The client includes the token in the HTTP Authorization header.

HTTP Basic Authentication : Sends username:password encoded with BASE64 in the Authorization header.

HTTPS Certificate Authentication (most strict) : Uses client certificates signed by a CA root certificate.

Note: Token and Basic authentication are one‑way; the client cannot verify the server. HTTPS certificate authentication supports mutual authentication.

Token Workflow

User sends username and password to log in; Server returns a token to the client; Client uses the token to access the server; Server returns the requested information.

Basic Authentication

When the server receives a request with 401 Unauthorized, it includes a WWW-Authenticate header containing the username and password.

HTTPS Certificate Authentication

Mutual authentication using certificates signed by the CA root certificate.

Components Requiring Certificates

Kubernetes components (kubectl, kubelet, kube-proxy) access the API Server via HTTPS on port 6443.

Certificates can be manually signed or automatically issued when a kubelet first contacts the API Server.

kubeconfig

The kubeconfig file contains cluster parameters (CA certificate, API Server address) and client credentials (certificate, private key). It allows components like kubelet and kube-proxy to switch clusters by specifying different kubeconfig files.

Each pod mounts its ServiceAccount token, ca.crt, and namespace under /var/run/secrets/kubernetes.io/serviceaccount/.

# View token, ca.crt, and namespace inside a pod
ls /var/run/secrets/kubernetes.io/serviceaccount/

Authorization (Authorization)

After authentication, authorization determines what resources the requester is allowed to access. Kubernetes supports several authorization modes set via the --authorization-mode flag.

AlwaysDeny : Deny all requests (useful for testing).

AlwaysAllow : Allow all requests (useful for testing).

ABAC (Attribute‑Based Access Control): Uses attribute rules; complex and requires API server restart on changes.

Webhook : Calls an external REST service for authorization decisions.

RBAC (Role‑Based Access Control): Default since v1.6; defines permissions via Roles and ClusterRoles.

RBAC Advantages

Covers both namespaced resources (Pod, Deployment, Service) and non‑resource URLs.

Managed via standard API objects; can be manipulated with kubectl or the API.

Changes take effect at runtime; no API server restart required.

RBAC API Objects

Four top‑level objects: Role: Grants permissions within a specific namespace. ClusterRole: Grants permissions cluster‑wide. RoleBinding: Binds a Role to subjects (User, Group, ServiceAccount) within a namespace. ClusterRoleBinding: Binds a ClusterRole to subjects across the entire cluster.

Example Role granting read access to Pods:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Example ClusterRole granting read access to Secrets:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding Example

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: zhangsan
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This binds the pod-reader role to user zhangsan in the default namespace.

ClusterRoleBinding Example

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

This grants every member of the manager group read access to Secrets across all namespaces.

Admission Control

Admission controllers are plugins that intercept requests to the API Server and can reject them based on custom policies. The default recommended list includes:

NamespaceLifecycle

LimitRanger

ServiceAccount

DefaultStorageClass

DefaultTolerationSeconds

MutatingAdmissionWebhook

ValidatingAdmissionWebhook

ResourceQuota

NodeRestriction

These plugins enforce namespace cleanup, resource quotas, automatic ServiceAccount injection, and more.

Practical Example: Restrict a User to a Specific Namespace

1. Create a Linux user monor and generate a certificate for it.

useradd -m monor
passwd monor

2. Install cfssl, cfssljson, and cfssl-certinfo tools, then generate a CSR and sign it with the cluster CA:

cat > monor-csr.json <<EOF
{
  "CN": "monor",
  "hosts": [],
  "key": {"algo": "rsa", "size": 2048},
  "names": [{"C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "System"}]
}
EOF
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes monor-csr.json | cfssljson -bare monor

3. Create a kubeconfig for the user:

APISERVER=$1
export KUBE_APISERVER="https://$APISERVER:6443"
kubectl config set-cluster kubernetes \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=monor.kubeconfig
kubectl config set-credentials monor \
  --client-key=/etc/kubernetes/pki/monor-key.pem \
  --client-certificate=/etc/kubernetes/pki/monor.pem \
  --embed-certs=true \
  --kubeconfig=monor.kubeconfig
kubectl config set-context kubernetes \
  --cluster=kubernetes \
  --user=monor \
  --namespace=test \
  --kubeconfig=monor.kubeconfig
kubectl config use-context kubernetes --kubeconfig=monor.kubeconfig

4. Create a namespace test and bind a Role to the user:

kubectl create ns test
cat > rbac.yaml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: test
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: test
subjects:
- kind: User
  name: monor
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
EOF
kubectl apply -f rbac.yaml

Now the user monor can list Pods only in the test namespace.

Testing the Permissions

su - monor
kubectl get pod -n test
kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pod-monor
spec:
  containers:
  - name: nginx
    image: nginx
EOF

If the user tries to access resources outside the bound namespace, the request is denied.

Granting Admin Privileges

kubectl create rolebinding monor-admin-binding --clusterrole=admin --user=monor --namespace=test

This gives monor full admin rights within the test namespace.

Summary – Kubernetes Security Mechanisms

Authentication : Token, Basic, and HTTPS certificate authentication.

Authorization : RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) and other modes.

Admission Control : Pluggable admission controllers enforce additional policies.

By combining these three layers, Kubernetes ensures that only verified and authorized entities can interact with the cluster, and admission controllers provide a final gatekeeper for request validation.