Kubernetes now underpins the majority of new cloud-native deployments across the European Union and, increasingly, across North Africa's fast-growing digital-services sector. Yet many teams still treat the moment a workload enters the cluster as a formality. It is not. Admission control is the layer where every create, update, and delete request to the Kubernetes API server is intercepted, inspected, and then allowed, mutated, or rejected before anything is written to etcd. It is the single most important enforcement point in a cluster, and in 2026 it has finally matured from a bolt-on into a first-class, declarative discipline usually described as policy-as-code.
The shift matters because the old guardrail, Pod Security Policies, was removed back in Kubernetes 1.25 and is now absent from every supported release. In its place sits a richer but more confusing landscape: built-in Pod Security Admission, the Common Expression Language that powers native ValidatingAdmissionPolicy and the newer MutatingAdmissionPolicy, and mature third-party engines such as Kyverno and Open Policy Agent Gatekeeper. For a nearshore engineering team in Tunis running clusters on behalf of EU clients under GDPR and NIS2, getting this layer right is the difference between a defensible, auditable platform and a heap of YAML that nobody can reason about. This article maps how the pieces fit and how to roll them out without slowing delivery.
Why the admission chain is the real security boundary
Every request to the API server travels a fixed path: authentication proves who you are, authorization through role-based access control decides whether you may act, and only then does the admission chain decide what the resulting object is actually allowed to look like. Understanding that ordering is the whole game, because it tells you where each class of control belongs.
- ▸Mutating admission runs first: this stage rewrites objects in flight, injecting sidecars, pinning images to digests, defaulting a securityContext, or adding required labels. It is powerful and therefore dangerous, so mutations must be minimal and predictable.
- ▸Validating admission runs last before persistence: this is the final veto. If a pod requests privileged mode or a hostPath mount that violates policy, this is where it dies with a clear rejection message.
- ▸RBAC decides who, admission decides what: the two are complementary. Role-based access control cannot express the rule that no container may run as root; only admission can. Treating RBAC as your whole policy story is a common and costly mistake.
- ▸etcd is the source of truth: once an object is persisted, controllers act on it immediately. There is no second checkpoint, which is why weak admission control cannot be compensated for downstream.
From Pod Security Policies to the 2026 stack
Pod Security Policies were flexible but notoriously hard to reason about, and their removal forced the ecosystem to grow up. The replacement is layered rather than monolithic.
Pod Security Admission is the built-in floor. It enforces the three standard Pod Security Standards, privileged, baseline, and restricted, at the namespace level using labels, and it supports three modes: enforce, audit, and warn. It is free, always present, and a sensible first line of defense, but it is deliberately coarse. It cannot inspect image provenance, cannot enforce team-specific labels, and cannot express conditional logic. That is where a policy engine earns its place, sitting above the built-in floor to encode the rules your organization actually cares about.
Choosing between Kyverno, Gatekeeper, and native policies
There is no universally correct engine, only trade-offs that depend on your team's skills and your latency budget.
- ▸Native ValidatingAdmissionPolicy with CEL: shipped in-tree and stable since Kubernetes 1.30, it evaluates Common Expression Language rules inside the API server with no external webhook. That means no extra network hop, no separate pod to keep alive, and no availability single point of failure. The cost is expressiveness: it validates, and the companion MutatingAdmissionPolicy is still stabilizing, so complex generation logic lives elsewhere.
- ▸Kyverno: policies are written in familiar YAML rather than a new language, which lowers the barrier for platform teams. It validates, mutates, generates resources, and verifies image signatures, all from one declarative style. It runs as a webhook, so you must plan for its availability.
- ▸Open Policy Agent Gatekeeper: built on Rego, it is the most powerful option for teams that already use OPA across non-Kubernetes systems and want one policy language everywhere. Rego has a learning curve, but constraint templates make policies reusable and testable.
- ▸The webhook trade-off: any external admission webhook sits on the critical path of cluster operations. A misconfigured failurePolicy set to Fail can wedge a cluster if the webhook is down, while Ignore can silently skip enforcement. Native CEL policies sidestep this entirely, which is why many teams now run a hybrid: CEL for the non-negotiable denials, an engine for mutation and image verification.
Mapping policy to CIS Benchmarks and zero trust
Policy-as-code is most defensible when each rule traces back to a recognized control rather than a personal preference. The CIS Kubernetes Benchmark is the natural spine: its workload section maps almost one-to-one onto restricted Pod Security Standards, covering non-root execution, dropped Linux capabilities, read-only root filesystems, and seccomp profiles. Wiring those benchmark items into enforced policies turns an annual audit scramble into a continuous, machine-checked posture.
The deeper principle is NIST Special Publication 800-207, the zero trust architecture. Admission control is where zero trust becomes concrete inside a cluster: deny by default, grant least privilege, and never assume a workload is trustworthy because of where it came from. For EU clients bound by NIS2, and for financial-sector clients facing DORA, this traceability is not optional. An auditor asking how you prevent privileged containers wants to see an enforced policy and its ISO 27001 Annex A mapping, not a wiki page describing good intentions. North African service providers that can present this evidence chain compete directly with more expensive EU-based platforms on trust, not just cost.
A numbered rollout roadmap
1. Inventory and baseline: catalog every namespace, its workloads, and their current securityContext. You cannot enforce what you have not measured. 2. Enable Pod Security Admission in warn and audit modes: start with the baseline standard cluster-wide, then target restricted for namespaces that can take it. 3. Author engine policies in audit mode: write your first Kyverno or CEL rules to report violations only, never to block, so teams see the impact before it bites. 4. Route policy reports into dashboards and CI: surface violations in pull requests using tools such as conftest or the Kyverno CLI so problems are caught before they reach a cluster. 5. Promote to enforce namespace by namespace: flip enforcement on for low-risk namespaces first, learn, then widen the blast radius deliberately. 6. Add image verification at admission: require signed images verified with cosign and Sigstore, tying this layer to your supply-chain controls. 7. Codify exceptions with an owner and an expiry: every waiver is a policy object with a name, a justification, and a date it dies. No permanent exceptions. 8. Test policies continuously: treat policies as software with unit tests and end-to-end checks using chainsaw or an equivalent, run in CI on every change.
What to do this quarter
Pick one cluster and make it exemplary rather than trying to fix everything at once. Turn on Pod Security Admission in audit mode today; it costs nothing and reveals your true exposure within hours. Choose a single engine based on your team's language comfort, then write the three policies that matter most: block privileged pods, forbid the latest image tag, and require resource limits. Move image-signature verification onto the roadmap even if it is not this month's work. Finally, write down the exception process before you need it, because the first urgent waiver request under pressure is exactly when undocumented shortcuts become permanent risk.
Outlook
The direction of travel is clear: more policy logic is moving into the API server itself through CEL, reducing reliance on webhooks and shrinking the attack surface, while engines specialize in mutation, generation, and supply-chain verification. Expect admission control to fuse ever more tightly with image provenance and runtime detection into a single, continuously verified pipeline from commit to running pod. For teams across Tunisia and North Africa building platforms for European customers, mastering this layer is one of the highest-leverage investments available in 2026, because it converts security from a periodic audit event into an always-on, provable property of the platform itself.