Day 67: Admission controllers; OPA/Gatekeeper
Enforcing policy before an object is ever created
An admission controller intercepts requests to the API server after authentication/authorization but before an object is persisted, and can mutate or reject it. This is how Pod Security Standards are actually enforced (rejecting a Pod that violates the policy before it's ever scheduled), and it's an extensible mechanism — you can write your own.
OPA (Open Policy Agent) / Gatekeeper lets you write custom admission policies as code (in a policy language called Rego) — "every Deployment must have resource limits set," "images must come from our approved registry," "no Service may be of type LoadBalancer" — enforced automatically at admission time, cluster-wide.
violation[msg] {
container := input.review.object.spec.containers[_]
not container.resources.limits
msg := "Every container must set resource limits"
}This is shift-left, applied to cluster config
Instead of discovering a missing resource limit or a disallowed image registry during an incident, Gatekeeper rejects the offending manifest at creation time — the same 'catch it before it becomes a problem' philosophy as Phase 14's CI security gates, just enforced at the cluster boundary instead of the pipeline.
Key terms
- Admission controller
- Intercepts API requests after auth, before persistence, and can mutate or reject them.
- OPA/Gatekeeper
- A policy engine letting you write and enforce custom admission rules as code.
Why would a team use OPA/Gatekeeper to reject Deployments without resource limits, instead of just relying on code review?
