Admission Control

Admission control is Kubernetes’ final security checkpoint before requests are persisted to etcd. Think of it as a security guard at the entrance of a building—even if you have the right keycard (authentication) and permission to enter (authorization), the guard can still stop you if you’re carrying something prohibited.

What is Admission Control?

Admission control intercepts requests to the Kubernetes API after authentication and authorization but before the object is created or modified. It can:

Validate requests and reject invalid ones
Mutate requests to add defaults or modify values
Audit requests for compliance and security

flowchart TD A[API Request] --> B[Authentication] B --> C[Authorization] C --> D[Admission Control] D --> E{Mutating Webhooks} E -->|Modify| F{Validating Webhooks} E -->|Pass Through| F F -->|Reject| G[403 Forbidden] F -->|Allow| H[Object Created/Updated] H --> I[etcd]

When Admission Control Runs

Admission control runs in two phases:

Mutating Admission - Can modify requests (add defaults, inject sidecars, etc.)
Validating Admission - Can only accept or reject requests (enforce policies, validate schemas)

Both phases run for:

CREATE operations (new resources)
UPDATE operations (modifying existing resources)
DELETE operations (for some webhooks)
CONNECT operations (for proxy requests)

Types of Admission Controllers

Built-in Admission Controllers

Kubernetes includes many built-in admission controllers:

NamespaceLifecycle - Prevents creation in non-existent namespaces
LimitRanger - Enforces resource limits
ResourceQuota - Enforces namespace quotas
PodSecurityPolicy - Enforces pod security policies (deprecated, use Pod Security Standards)
ServiceAccount - Automatically creates ServiceAccounts
DefaultStorageClass - Sets default storage class
DefaultTolerationSeconds - Adds default tolerations

Dynamic Admission Controllers (Webhooks)

For custom logic, you can create:

MutatingAdmissionWebhook - Custom mutation logic
ValidatingAdmissionWebhook - Custom validation logic

These webhooks are more flexible and can be updated without restarting the API server.

Admission Control Flow

sequenceDiagram participant Client participant API Server participant Mutating as Mutating Webhooks participant Validating as Validating Webhooks participant etcd Client->>API Server: Create Pod Request API Server->>Mutating: Call Mutating Webhooks Mutating-->>API Server: Modified Request API Server->>Validating: Call Validating Webhooks Validating-->>API Server: Accept/Reject alt Accepted API Server->>etcd: Store Object API Server-->>Client: Success else Rejected API Server-->>Client: 403 Forbidden end

Practical Example

Here’s how admission control prevents a security issue:

Without Admission Control:

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      runAsUser: 0  # Running as root - security risk!

With Validating Webhook: The webhook rejects this pod because it runs as root, preventing the security risk.

With Mutating Webhook: The webhook automatically modifies the pod to run as a non-root user:

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      runAsUser: 1000  # Automatically changed to non-root

Common Use Cases

Security Enforcement

Prevent running containers as root
Require specific security contexts
Block privileged containers
Enforce network policies

Resource Management

Set default resource requests and limits
Enforce resource quotas
Validate resource constraints

Configuration Management

Inject sidecar containers
Add default labels and annotations
Set default service accounts
Configure default storage classes

Compliance

Enforce organizational policies
Validate naming conventions
Require specific labels or annotations
Block deprecated APIs

Best Practices

Use validating webhooks for security - Don’t rely on mutation for security; validate explicitly
Make webhooks fast - Slow webhooks delay all API requests
Handle failures gracefully - Decide whether to fail open or fail closed
Test thoroughly - Webhooks affect all API requests
Monitor webhook performance - Track latency and error rates
Use namespaces for testing - Test webhooks in non-production namespaces first

Webhook Configuration

Admission webhooks are configured via:

MutatingWebhookConfiguration - Defines mutating webhooks
ValidatingWebhookConfiguration - Defines validating webhooks

Both specify:

Which resources to intercept
When to call the webhook (CREATE, UPDATE, DELETE)
The webhook endpoint URL
Failure policy (Fail or Ignore)

Troubleshooting

Check webhook configurations:

kubectl get mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations

View webhook details:

kubectl describe mutatingwebhookconfiguration my-webhook
kubectl describe validatingwebhookconfiguration my-webhook

Test without webhooks:

Temporarily disable webhooks to test if they’re causing issues:

kubectl delete mutatingwebhookconfiguration my-webhook
kubectl delete validatingwebhookconfiguration my-webhook

Check API server logs:

kubectl logs -n kube-system kube-apiserver-<node-name> | grep webhook

Topics

Webhooks - Creating and managing admission webhooks
Pod Security Standards - Built-in pod security enforcement