Lesson 08 — Kubernetes Admission Controllers

Learning Objectives

By the end of this lesson, you will be able to:

Explain what Kubernetes Admission Controllers are
Understand where Admission Controllers fit within the Kubernetes API request lifecycle
Differentiate between built-in and dynamic Admission Controllers
Explain the differences between mutating and validating admission webhooks
Understand how Admission Controllers improve Kubernetes security
Learn how Amazon EKS uses Admission Controllers
Compare Pod Security Admission, Gatekeeper and Kyverno
Design enterprise admission control strategies
Monitor Admission Controller health and performance
Apply Admission Controllers in enterprise Kubernetes environments

Why This Matters

Every Kubernetes resource enters the cluster through the Kubernetes API Server.

Whether a user creates:

Pods
Deployments
Services
Namespaces
Secrets
ConfigMaps
RBAC objects
Network Policies

the request always passes through the Kubernetes API.

Without Admission Controllers, Kubernetes would only verify:

Authentication
Authorisation
Object schema

It would not automatically determine whether the requested configuration complies with your organisation’s security policies.

For example, Kubernetes RBAC may allow a developer to create Pods, but it does not determine whether the Pod:

Runs as root
Uses privileged mode
Uses an approved image
Mounts the host filesystem
Has resource limits
Uses an approved Service Account

Admission Controllers bridge this gap by evaluating Kubernetes resources before they are stored.

They act as Kubernetes’ final security checkpoint.

What is an Admission Controller?

An Admission Controller is a component that intercepts Kubernetes API requests after authentication and authorisation but before the object is stored in etcd.

It can:

Validate requests
Modify requests
Reject requests
Add defaults
Enforce enterprise security policies

Kubernetes API Request

↓

Authentication

↓

Authorisation

↓

Admission Controllers

↓

Object Validation

↓

Stored in etcd

Admission Controllers therefore enforce security before workloads enter the cluster.

Kubernetes API Request Lifecycle

Every Kubernetes request follows a predictable sequence.

kubectl apply

↓

Kubernetes API Server

↓

Authentication

↓

Authorisation (RBAC)

↓

Mutating Admission Controllers

↓

Object Validation

↓

Validating Admission Controllers

↓

Resource Stored

↓

Controller Reconciliation

Notice that admission happens before Kubernetes persists the object.

Security Responsibilities

Each stage answers a different security question.

Stage	Question
Authentication	Who are you?
Authorisation	Are you allowed to perform this action?
Admission	Is this configuration acceptable?
Validation	Does the object follow the Kubernetes schema?
Runtime	What is the workload doing now?

These layers work together to provide defence in depth.

Why Admission Controllers Matter

Without Admission Controllers, developers could create workloads such as:

securityContext:
  privileged: true

hostNetwork: true

hostPID: true

RBAC may allow Pod creation.

Admission Controllers decide whether those settings should actually be accepted.

Developer

↓

RBAC Allows Pod Creation

↓

Admission Controller

↓

Security Policy Evaluation

↓

Allowed or Denied

Admission Controller Types

Admission Controllers are divided into two broad categories.

Type	Purpose
Built-in Admission Controllers	Native Kubernetes controllers
Dynamic Admission Controllers	External webhook-based controllers

Both operate during admission but serve different purposes.

Built-in Admission Controllers

Built-in Admission Controllers are compiled into Kubernetes.

Examples include:

NamespaceLifecycle
LimitRanger
ResourceQuota
DefaultStorageClass
PodSecurity
RuntimeClass
ServiceAccount
DefaultTolerationSeconds
Priority

These controllers provide core Kubernetes behaviour.

Dynamic Admission Controllers

Dynamic Admission Controllers use admission webhooks.

External tools such as:

Kyverno
OPA Gatekeeper
Custom admission webhooks

API Request

↓

Admission Webhook

↓

External Policy Engine

↓

Allow or Deny

Dynamic controllers make Kubernetes highly extensible.

Mutating vs Validating Admission Controllers

Admission controllers perform one of two primary functions.

Incoming Request

↓

Mutating Admission

↓

Object Modified

↓

Validating Admission

↓

Allowed or Denied

Mutating controllers modify objects.

Validating controllers inspect objects.

Mutating Admission Controllers

Mutating controllers change Kubernetes resources before validation.

Examples include:

Adding labels
Adding annotations
Setting default values
Adding security settings
Injecting sidecars
Adding imagePullSecrets
Setting RuntimeClass
Setting seccomp profiles

Developer Manifest

↓

Mutating Controller

↓

Additional Secure Defaults

↓

Validation

Mutation Example

Developer submits:

metadata:
  name: payment-api

Mutating Admission Controller adds:

metadata:
  name: payment-api

  labels:
    owner: platform-team

The stored resource contains the added label.

Common Mutation Use Cases

Mutation commonly adds:

Ownership labels
Cost-centre labels
Default resource requests
Security annotations
RuntimeClass
seccomp profiles
ImagePullSecrets
Sidecar containers
Service mesh configuration

Mutation reduces manual configuration.

Validation Admission Controllers

Validation controllers inspect resources but do not modify them.

Instead they decide:

Compliant?

↓

Yes → Admit

No → Reject

Validation is ideal for:

Security requirements
Compliance
Governance
Standardisation

Validation Example

Enterprise requirement:

Containers must not run as root.

Developer submits:

securityContext:
  runAsNonRoot: false

Validation result:

Admission Denied

Reason:

Containers must run as non-root.

Built-in Admission Controllers

Let’s examine several important built-in controllers.

NamespaceLifecycle

Ensures resources are created only inside valid namespaces.

Prevents:

Creating resources inside deleted namespaces
Using invalid namespaces
Namespace inconsistencies

LimitRanger

Automatically applies or validates:

CPU requests
CPU limits
Memory requests
Memory limits
Storage requests

Example:

Namespace

↓

LimitRange

↓

Developer Omits Limits

↓

Defaults Applied

ResourceQuota

Restricts total namespace resource consumption.

Controls may include:

CPU
Memory
Pods
Services
PersistentVolumeClaims
Secrets
ConfigMaps

Example:

Namespace

↓

ResourceQuota

↓

Quota Exceeded

↓

Deployment Rejected

ServiceAccount Admission Controller

Automatically assigns Service Accounts to Pods.

Without this controller:

Pods might have no Service Account.

It also mounts Service Account tokens when configured.

DefaultStorageClass

Automatically assigns the cluster’s default StorageClass when none is specified.

This simplifies storage provisioning.

RuntimeClass Admission

Automatically associates workloads with an appropriate container runtime.

Useful for:

gVisor
Kata Containers
Alternative runtimes

Pod Security Admission

Pod Security Admission replaces the deprecated PodSecurityPolicy.

It enforces three security profiles.

Profile	Purpose
Privileged	Minimal restrictions
Baseline	Prevent common privilege escalation
Restricted	Strong security baseline

Production workloads generally target the Restricted profile.

Pod Security Admission Workflow

Pod Creation

↓

Pod Security Admission

↓

Profile Evaluation

↓

Allowed or Denied

Pod Security Modes

Pod Security Admission supports:

Enforce
Audit
Warn

These support gradual adoption.

Example Namespace Labels

kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted

Additional labels may enable:

Audit
Warn

This provides staged rollout.

Admission Webhooks

Dynamic Admission Controllers communicate through admission webhooks.

Two webhook types exist.

Webhook	Purpose
MutatingAdmissionWebhook	Modifies resources
ValidatingAdmissionWebhook	Validates resources

Admission Webhook Architecture

Developer

↓

API Server

↓

Admission Webhook

↓

External Policy Engine

↓

API Server

↓

Stored Object

Webhook Response

A webhook typically returns:

Allowed

or

Denied

or

Mutated Object

The Kubernetes API Server honours the decision.

Gatekeeper as a Validating Webhook

OPA Gatekeeper operates primarily as a validating admission webhook.

Example policies:

Block privileged Pods
Require labels
Require resource limits
Restrict registries

Pod Request

↓

Gatekeeper

↓

Constraint Evaluation

↓

Allow or Deny

Kyverno Admission Flow

Kyverno supports both mutation and validation.

Incoming Resource

↓

Mutation

↓

Validation

↓

Stored

This makes Kyverno suitable for enforcing and automatically correcting configurations.

Admission Controller Order

A simplified order is:

Authentication

↓

RBAC

↓

Mutating Controllers

↓

Validation

↓

Validating Controllers

↓

Persist Resource

Understanding the order is important because mutations occur before validation.

Multiple Webhooks

A request may pass through several webhooks.

Pod

↓

Webhook 1

↓

Webhook 2

↓

Webhook 3

↓

Stored

Each webhook can:

Modify
Validate
Reject

Poorly designed webhook chains may introduce latency.

Failure Policies

Admission webhooks define behaviour when unavailable.

Two common modes:

Fail
Ignore

Fail Closed

Webhook Offline

↓

Request Rejected

Advantages:

Strong security
No policy bypass

Disadvantages:

Deployments may stop

Fail Open

Webhook Offline

↓

Request Allowed

Advantages:

High availability

Disadvantages:

Policy bypass becomes possible

Security-critical workloads generally prefer stricter controls after careful operational planning.

Admission Latency

Every webhook increases admission processing time.

Enterprise monitoring should measure:

Admission latency
Webhook response time
Error rate
Timeout rate

Slow webhooks slow the Kubernetes API.

Amazon EKS Admission Controllers

Amazon EKS supports:

Built-in Kubernetes admission controllers
Pod Security Admission
Dynamic admission webhooks
Kyverno
Gatekeeper
Custom webhooks

Amazon EKS

↓

API Server

↓

Built-in Controllers

↓

Admission Webhooks

↓

etcd

Enterprise Admission Architecture

Developer

↓

GitOps

↓

API Server

↓

Pod Security Admission

↓

Kyverno

↓

Gatekeeper

↓

Validation

↓

Amazon EKS

Multiple layers provide stronger governance.

Admission Controller Use Cases

Typical enterprise controls include:

Deny privileged Pods
Require resource limits
Require non-root execution
Require labels
Restrict namespaces
Restrict image registries
Require signed images
Prevent public Services
Require Network Policies
Require approved Service Accounts

Software Supply Chain Protection

Admission Controllers can verify:

Approved registry
Image signature
Image digest
Provenance
Attestations

Container Image

↓

Verification

↓

Admission

↓

Deployment

This prevents deployment of untrusted images.

Admission Controllers and GitOps

Policies should also be validated before reaching the cluster.

Git Commit

↓

CI/CD

↓

Policy Tests

↓

GitOps

↓

Admission Controllers

↓

Production

This provides multiple checkpoints.

Monitoring Admission Controllers

Important metrics include:

Admission latency
Webhook failures
Request volume
Denied requests
Warning events
Mutation count
Controller availability
Audit findings

Enterprise Monitoring Architecture

Admission Events

↓

Prometheus

↓

Grafana

↓

CloudWatch

↓

SIEM

↓

SOC Investigation

Policy violations should become security events where appropriate.

High Availability

Admission Controllers participate in the Kubernetes control plane.

Production deployments should include:

Multiple replicas
Health probes
PodDisruptionBudgets
Anti-affinity
Monitoring
Certificate management
Upgrade testing

Common Security Risks

Disabled Admission Controllers

Policies cannot be enforced.

Control: Verify required controllers are enabled.

Fail-Open Webhooks

Unavailable webhooks may permit insecure deployments.

Control: Evaluate failure behaviour carefully.

Untested Policies

New policies may block production workloads.

Control: Use Audit or Warn modes before enforcement.

Excessive Mutation

Hidden mutations may confuse developers.

Control: Document mutations and use them only where appropriate.

Admission Bottlenecks

Slow policies reduce cluster performance.

Control: Monitor admission latency and optimise webhook design.

Policy Drift

Different clusters enforce different policies.

Control: Manage policies centrally through GitOps.

Enterprise Implementation Strategy

Phase 1 — Define Security Requirements

Identify enterprise standards
Map CIS, NSA and NIST guidance
Define mandatory admission controls
Assign ownership

Phase 2 — Enable Built-in Controllers

Pod Security Admission
ResourceQuota
LimitRanger
ServiceAccount
NamespaceLifecycle

Phase 3 — Deploy Dynamic Controllers

Kyverno
Gatekeeper
Custom admission webhooks where required

Phase 4 — Test Policies

Use non-production clusters
Audit mode
Warn mode
Application validation
Performance testing

Phase 5 — Enable Enforcement

Production rollout
Monitor denied requests
Track exceptions
Review policy effectiveness

Phase 6 — Continuous Governance

GitOps deployment
Policy version control
Compliance reporting
Regular reviews
Security monitoring
Framework mapping updates

Enterprise Best Practices

As a Cloud Security Engineer:

Treat Admission Controllers as critical security infrastructure.
Use Pod Security Admission as the baseline workload protection.
Apply Kyverno or Gatekeeper for enterprise-specific controls.
Keep mutation predictable and transparent.
Validate policies before production rollout.
Monitor admission latency and webhook health.
Protect admission webhook configurations.
Store policies in Git and deploy through GitOps.
Integrate admission events with SIEM platforms.
Regularly review policy effectiveness and exceptions.

Real-World Scenario

A multinational bank operates over 200 Amazon EKS clusters supporting online banking applications.

An internal audit finds inconsistent security controls across environments. Some teams deploy privileged containers, others use public container registries, and several namespaces lack resource limits and ownership metadata.

To standardise governance, the Cloud Security team implements a layered admission control strategy:

Pod Security Admission enforces the Restricted profile for production namespaces.
Kyverno validates approved Amazon ECR registries, required labels, and image signatures while mutating secure default settings where appropriate.
OPA Gatekeeper enforces complex organisation-wide governance policies such as namespace naming standards and approved Service types.
All admission events are forwarded to Amazon CloudWatch, collected by the enterprise SIEM, and monitored by the SOC.
Policies are managed through GitOps with staged rollouts using Audit mode before Enforce mode.

As a result, insecure workloads are blocked before deployment, compliance improves significantly, and the organisation achieves a consistent Kubernetes security posture across all production environments.

Key Takeaways

Admission Controllers evaluate Kubernetes resources before they are stored.
They operate after authentication and authorisation.
Built-in controllers provide core Kubernetes governance.
Dynamic admission webhooks enable custom enterprise policies.
Mutating controllers modify resources.
Validating controllers approve or reject resources.
Pod Security Admission provides native workload security enforcement.
Kyverno and Gatekeeper extend admission capabilities for enterprise governance.
Admission Controllers are essential for preventing insecure deployments.
Monitoring webhook health and admission latency is critical in production.
Admission policies should be version-controlled, tested and deployed through GitOps.

Knowledge Check

1. At which stage do Admission Controllers operate?

Answer: After authentication and authorisation, but before the resource is stored in etcd.

2. What is the difference between a Mutating Admission Controller and a Validating Admission Controller?

Answer: Mutating Admission Controllers modify resources before validation, while Validating Admission Controllers inspect resources and either allow or reject them without modifying them.

3. Name three built-in Kubernetes Admission Controllers.

Answer:

Pod Security Admission
ResourceQuota
LimitRanger

4. Why are Admission Controllers important even when RBAC is configured?

Answer: RBAC controls who can perform an action, while Admission Controllers determine whether the requested resource configuration complies with security and governance policies.

5. Why should Admission Controller events be monitored?

Answer: Monitoring helps detect policy violations, webhook failures, admission latency issues, attempted policy bypasses and overall compliance across Kubernetes environments.

What’s Next?

In the next lesson, we will explore Enterprise Kubernetes Governance, including policy lifecycle management, multi-cluster governance, compliance reporting and enterprise operating models for large-scale Amazon EKS environments.

➡️ Next Lesson: Lesson 09 — Enterprise Governance