Kubernetes Admission Controllers Checklist for Secure Workloads
Admission controllers enforce policy before workloads run, blocking misconfigurations that firewalls cannot see inside your cluster.
Use admission controllers to validate and mutate requests before Kubernetes stores them. This checklist covers identity, image safety, network rules, and resource limits. Apply these checks to stop insecure pods from starting in the first place.
Who Uses This Checklist
This list serves platform engineers and security architects managing Kubernetes clusters. You use it to verify that your admission control layer stops insecure configurations before they run. It applies to both initial setup and ongoing audits of your cluster policy.
Identity and Access Validation
Admission controllers check who is asking for changes and what they are allowed to do. This layer sits between the API server and the etcd datastore.
- Verify service account tokens are short-lived: Long-lived tokens increase the risk of credential theft and lateral movement.
- Enforce least privilege on pod security contexts: Prevents containers from running as root or gaining unnecessary host access.
- Block privileged containers by default: Privileged mode bypasses kernel security, giving code full host access.
- Require specific service accounts for workloads: Ties workload identity to specific permissions rather than broad cluster roles.
- Validate RBAC bindings before creation: Stops overly permissive role assignments that grant cluster-admin access to standard users.
Imagine a developer deploys a pod that requests cluster-admin rights. A well-configured webhook rejects this request immediately. This prevents accidental privilege escalation that could compromise the entire cluster.
Container Image and Runtime Safety
You must ensure that the code running inside containers is safe and minimal. Admission controllers can inspect image metadata and runtime settings before the container starts.
- Reject images from untrusted registries: Prevents supply chain attacks from malicious or compromised public repositories.
- Enforce image signing verification: Ensures only code approved by your build pipeline runs in production.
- Block images with known vulnerabilities: Stops deployment of containers with critical security flaws already present.
- Require read-only root filesystems: Prevents attackers from modifying binaries or injecting malware into the running container.
- Drop all unnecessary Linux capabilities: Reduces the attack surface by removing permissions like NET_RAW or SYS_ADMIN.
See also: insecure container images
Network and Resource Boundaries
Workloads need strict boundaries for network access and resource consumption. These checks prevent noisy neighbors and limit the blast radius of a breach.
- Require network policies for all pods: Isolate workloads so a compromised pod cannot scan or communicate with other services.
- Enforce resource requests and limits: Prevents a single workload from consuming all CPU or memory on a node.
- Block hostNetwork and hostPID usage: Stops containers from accessing the host’s network stack or process list directly.
- Validate ingress and egress rules: Ensures traffic flows only through approved paths and ports.
- Set limits on ephemeral storage: Prevents disk exhaustion that could crash other pods on the same node.
Suppose a compromised pod tries to scan your internal network. Without network policies, it succeeds. With strict admission controls, the pod never starts without an explicit allow rule.
Webhook and Controller Reliability
Admission controllers often run as external webhooks. These components introduce new failure modes that can take your cluster offline if not managed carefully.
- Configure webhook timeouts appropriately: Prevents slow validators from hanging API requests and degrading cluster performance.
- Use failure-policy=Ignore for non-critical checks: Ensures the cluster remains available even if the webhook service goes down.
- Monitor webhook latency and error rates: Detects performance degradation before it impacts user deployments.
- Secure webhook TLS certificates: Prevents man-in-the-middle attacks on the policy enforcement channel.
- Implement mutual TLS for webhook authentication: Ensures only authorized controllers can modify or reject requests.
See also: cloud security architecture
See also: serverless security risks
See also: IaaS, PaaS and SaaS security: small business defense strategies
Audit and Continuous Improvement
Admission control is not a one-time setup. You must monitor its effectiveness and update rules as your environment changes.
- Log all admission decisions: Provides an audit trail for compliance and incident investigation.
- Review blocked requests regularly: Identifies legitimate workflows that need policy exceptions or updates.
- Test controllers against new Kubernetes versions: Ensures compatibility and prevents breakage during cluster upgrades.
- Document policy exceptions clearly: Tracks why certain workloads bypass standard security rules.
- Integrate with CI/CD pipelines: Catches policy violations before code reaches the cluster, reducing feedback loops.
See also: federated identity
See also: cloud access security brokers (CASB)
Key takeaways
- Validation blocks bad requests before they exist in the cluster state.
- Mutation automatically fixes missing security settings during deployment.
- Webhooks add flexibility but introduce latency and availability risks.
Admission controllers enforce security at the point of creation, stopping misconfigurations before they become vulnerabilities. Review your webhook configurations and failure policies to ensure reliability alongside security.
Frequently asked questions
What is the difference between validation and mutation webhooks?
Validation webhooks reject or accept requests based on policy, while mutation webhooks modify the request object before it is stored.
Can admission controllers protect against runtime attacks?
No, they only check requests before the pod starts. You need runtime security tools to detect attacks after the container is running.
How do I handle webhook failures during cluster upgrades?
Set failure-policy to Ignore for non-critical checks so the cluster remains operational if the webhook service is temporarily unavailable.
Do admission controllers replace network security groups?
No, they complement them. Admission controllers enforce policy at the API level, while network security groups control traffic at the infrastructure level.
How this guide was produced: written by the CloudSec Press editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
