Admission Controllers enforce security, validation, mutation, and governance rules on every API request before the object is stored in etcd. They act as gatekeepers between the API server and the cluster state. When a pod, deployment, or any Kubernetes resource is created or modified, admission controllers can validate, mutate, or deny the request based on configured policies.

They are one of the most powerful security layers in Kubernetes because they control what enters the cluster.

What Admission Controllers Do

Admission controllers handle two major functions:

• Mutation – modify incoming requests (add defaults, inject sidecars, enforce labels)
• Validation – approve or deny requests based on policies

Controllers run after authentication and authorization but before persistence.

They enforce rules such as:

• enforcing Pod Security Standards
• injecting default configurations
• scanning images
• blocking privileged pods
• validating resource quotas
• ensuring required labels are present
• integrating with external policy engines
• preventing insecure configurations

Admission controllers operate on all API object types.

Built-In Admission Controllers

Kubernetes includes multiple controllers that enforce security and governance:

• NamespaceLifecycle – prevents creating resources in terminating namespaces
• LimitRanger – enforces resource limits and defaults
• ResourceQuota – enforces CPU, memory, object count quotas
• PodSecurity – enforces Pod Security Standards
• ServiceAccount – assigns service accounts automatically
• NodeRestriction – restricts kubelet actions
• TaintNodesByCondition – updates node taints automatically
• DefaultStorageClass – assigns default storage classes
• MutatingAdmissionWebhook – integrates external mutators
• ValidatingAdmissionWebhook – integrates custom validators

Admission controllers are the core of cluster governance.

Admission Webhooks

Admission webhooks extend Kubernetes with custom logic.

Mutating Admission Webhook

Modifies objects before they are stored.
Used for:

• sidecar injection (Istio, Linkerd)
• adding default labels
• enforcing image registries
• injecting security context defaults

Validating Admission Webhook

Validates objects and can deny requests.
Used for:

• enforcing zero-trust rules
• custom compliance logic
• policy-as-code (OPA Gatekeeper, Kyverno)

Webhooks run external services that communicate with the API server.

How Admission Controller Flow Works

When a client sends a request:

API server receives request
Authentication checks identity
Authorization checks allowed actions
Admission controllers run sequentially:
• built-in mutating controllers
• custom mutating webhooks
• built-in validating controllers
• validating webhooks
Object is stored in etcd if valid

Any controller can modify or reject the request.

Mutating vs Validating

Mutating

Changes resource before validation:

• add capabilities
• remove unsafe fields
• inject defaults
• modify images
• add sidecars

Validating

Rejects invalid or unsafe configurations:

• privileged pods
• missing labels
• insecure volumes
• forbidden images
• non-compliant resources

Both are essential in DevSecOps.

Why Admission Controllers Are Critical in DevSecOps

They enforce:

• policy as code
• security baselines
• compliance automation
• cluster-wide standards
• zero-trust pod creation
• namespace-level governance

They prevent insecure workloads from ever entering the cluster.

Policy-as-Code Engines Using Admission Controllers

Many security tools extend admission through webhooks:

• Kyverno
• OPA Gatekeeper
• Kubewarden
• Falco Talon

These provide granular governance:

• enforce image signatures
• force non-root users
• deny privileged pods
• require TLS
• restrict registries
• validate config maps
• prevent sensitive mounts

Admission controllers are the backbone of these tools.

Full-Length Practical Section

Hands-on exercises for mastering Admission Controllers.

Practical 1: View Active Admission Controllers

Check API server flags:

kubectl cluster-info dump | grep admission

Or inspect control plane manifest in kubeadm clusters:

/etc/kubernetes/manifests/kube-apiserver.yaml

Practical 2: Test PodSecurity Admission

Label namespace:

kubectl label ns dev pod-security.kubernetes.io/enforce=restricted

Try running privileged pod; admission denies it.

Practical 3: Enable Namespace-Level Requirements

Require label:

kubectl label ns prod team=backend

Enforce via webhook later.

Practical 4: Build Mutating Webhook (Basic)

Create a webhook that adds a label to all pods.

Write MutatingWebhookConfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...

Webhook server injects:

metadata:
  labels:
    auto: "true"

Practical 5: Validate Unsafe Pods

Create ValidatingWebhookConfiguration that rejects:

privileged: true

Test by applying insecure pod.

Practical 6: View Admission Review Payload

Webhook receives JSON:

• request object
• user identity
• namespace
• old/new objects

Study payload to understand enforcement.

Practical 7: Create Admission Controller Logs

Enable audit logs:

--audit-log-path=/var/log/k8s-audit.log

Monitor webhook rejections.

Practical 8: Test LimitRanger Controller

Explicitly create pod without limits:

kubectl apply -f pod.yaml

Controller injects default resource requests and limits.

Practical 9: Test ResourceQuota Enforcer

Create quota:

apiVersion: v1
kind: ResourceQuota
...

Admission blocks exceeding resources.

Practical 10: Test NodeRestriction

Try modifying node objects using kubectl; denied.

Practical 11: Adding OPA Gatekeeper

Install:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

Test by creating constraint.

Practical 12: Write Gatekeeper Constraint

Example restriction:

privileged containers must be denied

Apply, test denial.

Practical 13: Use Kyverno to Enforce Non-Root Pods

Policy:

spec:
  validation:
    pattern:
      spec:
        securityContext:
          runAsNonRoot: true

Apply, test.

Practical 14: Enforce Allowed Registries

Block images not from private registry.

Practical 15: Inject Sidecar Using Mutating Webhook (Istio)

Deploy Istio; observe automatic sidecar injection.

Practical 16: Enforce Configuration Standards

Require every deployment to include:

• labels
• annotations
• resource limits

Webhook validates.

Practical 17: Validate Secrets Size or Type

Reject large secrets or unencrypted config.

Practical 18: Validate Pod Affinity Rules

Ensure deployments include anti-affinity.

Practical 19: Validate TLS on Ingress

Webhook checks:

• TLS block exists
• secret specified

Reject insecure ingress.

Practical 20: Build Complete Admission Controller Security Architecture

Combine:

• Pod Security Admission
• LimitRanger
• ResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• Kyverno or Gatekeeper
• auditing
• deny-all default enforcement
• non-root requirements
• allowed registry enforcement
• ingress TLS validation
• resource limit enforcement

This creates a complete zero-trust DevSecOps admission model.

Intel Dump

• Admission Controllers enforce validation and mutation on every API request
• run between auth and persistence layers
• built-in controllers enforce quotas, limits, namespace lifecycle, and Pod Security
• mutating and validating webhooks enable custom security logic
• used for sidecar injection, enforcing non-root, registry restrictions, label requirements
• practicals covered identifying controllers, testing PSS enforcement, building webhooks, using Gatekeeper/Kyverno, validating workload standards, and creating full admission-based security architecture