DevOps Dictionary

Kubernetes Admission Controller is a Kubernetes control plane component that checks requests to the Kubernetes API before the API server saves them to etcd. It can allow a request, reject it, or modify it first, which makes it useful for enforcing security, configuration, and operational rules across a cluster.

What it does

An admission controller runs after authentication and authorization, but before the requested object is persisted. For example, a user may have permission to create a Pod, but an admission controller can still block that Pod if it runs as root, uses a forbidden image registry, or lacks required labels.

Admission controllers commonly handle:

• Validation: Rejecting requests that violate policy, such as a Deployment without resource limits.
• Mutation: Changing requests before they are saved, such as adding default labels, sidecars, tolerations, or security settings.
• Governance: Enforcing naming, ownership, compliance, and environment-specific rules.
• Security controls: Blocking privileged containers, unsafe hostPath mounts, or images from untrusted registries.

How it works

When a client sends a request to the Kubernetes API server, the request goes through several steps:

1. The API server authenticates the caller.
2. Kubernetes checks whether the caller is authorized to perform the action.
3. Mutating admission controllers can modify the object.
4. Validating admission controllers check whether the final object is acceptable.
5. If the request passes all checks, the API server saves it to etcd.

Kubernetes includes built-in admission controllers, such as NamespaceLifecycle, ResourceQuota, and LimitRanger. Teams can also run their own admission logic through admission webhooks.

Admission webhooks

Admission webhooks let you extend Kubernetes admission behavior with custom services. The API server sends an admission review request to the webhook service, and the service returns a decision.

• MutatingAdmissionWebhook: Can patch the incoming object before Kubernetes stores it.
• ValidatingAdmissionWebhook: Can approve or reject the object after mutation.

Tools such as OPA Gatekeeper, Kyverno, and custom webhook services use this pattern to enforce cluster policy. For example, a platform team might require every workload created through GitOps, Terraform, or Crossplane to include an owner label and a cost-center label. If you manage workloads with infrastructure as code, admission controls can complement workflows such as deploying Kubernetes resources using Terraform.

Common use cases

• Require CPU and memory requests on every container.
• Block Pods that use privileged mode or host networking.
• Add standard labels, annotations, or sidecars automatically.
• Enforce allowed container registries, such as only permitting images from an internal registry.
• Prevent workloads from being deployed into protected namespaces.
• Apply environment-specific rules for staging, production, and regulated workloads.
• Control how platform-managed resources are created when using tools such as Crossplane, including patterns for deploying AWS resources using Crossplane on Kubernetes.

Simple example

Suppose a developer creates this Deployment without resource limits. A validating admission controller can reject it with a clear error message:

containers:
  - name: api
    image: example.com/api:1.2.3

The controller might return:

Denied: container "api" must define cpu and memory requests and limits

A mutating admission controller could take a different approach and add default values automatically, such as:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Benefits

• Consistent enforcement: The same rules apply whether a change comes from kubectl, CI/CD, Helm, Terraform, Argo CD, or an operator.
• Earlier failure: Bad configuration fails before it reaches the cluster state.
• Better security posture: Teams can block risky workload settings at the API boundary.
• Platform standards: Platform teams can enforce labels, resource limits, namespace rules, and approved deployment patterns.

Tradeoffs and limitations

• Webhook availability matters: If a required webhook is down and its failure policy is set to fail closed, valid deployments may be blocked.
• Latency can increase: Each webhook call adds time to API requests, especially during large deployments.
• Policy errors can break workflows: A poorly written rule can block critical changes, including emergency fixes.
• Ordering can be hard to reason about: Mutating webhooks may change objects before validating webhooks inspect them.
• Upgrade planning is important: Kubernetes API changes can affect admission policies and webhooks, so teams should test them during Kubernetes upgrades.

Admission controller vs RBAC

Role-Based Access Control, or RBAC, decides whether a user or service account can perform an action, such as creating a Deployment. An admission controller decides whether the specific object being created or changed is acceptable.

For example, RBAC may allow a CI/CD service account to create Deployments in the production namespace. An admission controller can still reject a Deployment that uses the latest image tag, lacks resource limits, or tries to mount the host filesystem.

Where it fits in a DevOps workflow

Admission controllers work well as a final cluster-side guardrail. They should not replace code review, CI checks, security scanning, or infrastructure testing. Instead, they catch unsafe or non-compliant changes at the Kubernetes API boundary, including changes made by automation.

This is useful when teams manage clusters through multiple paths, such as Helm charts, GitOps, Terraform, or Crossplane. For example, if a platform team lets application teams provision cloud dependencies through Kubernetes APIs, admission policies can help control which claims and managed resources are allowed. This pattern often appears in setups that deploy a Kubernetes app with AWS resources using Crossplane.