On a managed Kubernetes platform, the difference between a security finding and a security incident is timing. If you detect an over-permissioned pod after it is running, you have an exposure window. If you block it at admission, there is no window to close. On Azure Kubernetes Service (AKS), the tooling to make that shift is built in, and the principle is one I apply to container security generally: a control that runs at admission beats a control that reports after deployment.

The detect-only trap, in the AKS context

Cloud Security Posture Management tooling, including the posture features in Microsoft Defender for Cloud, is excellent at surfacing risky configurations: pods running as root, containers requesting host networking, workloads with no resource limits, services exposed more broadly than intended. But surfacing is not stopping. A detect-only posture leaves the misconfigured workload running while a human triages the alert. At scale, that triage step is exactly the kind of “someone has to remember” control that gets skipped under load.

The fix is to enforce at the moment a workload is submitted to the cluster.

How Azure Policy and Gatekeeper enforce at admission

AKS integrates the Azure Policy add-on, which is built on Open Policy Agent’s Gatekeeper, the same admission-control engine used across the cloud-native ecosystem. The model is policy as code at the Kubernetes admission layer:

  • Azure Policy gives you a managed catalog of Kubernetes policies and built-in initiatives (including pod-security baselines) that you assign at the subscription or resource-group level, so the same guardrails apply consistently across every AKS cluster in scope.
  • OPA Gatekeeper evaluates each admission request against constraint templates written in Rego. When a workload violates a constraint, the API server rejects it before it is ever scheduled.

In practice you author a rule once, for example, “deny any pod that runs as root” or “deny any service of type LoadBalancer without an approved exception”, and it fires on every deployment, in every cluster the policy is assigned to, with no dependence on anyone reviewing a dashboard.

A practical baseline to start from

If you are standing this up on AKS, a sensible first set of admission controls maps directly to the Kubernetes Pod Security Standards:

  • Deny privileged containers and privilege escalation.
  • Deny host namespace sharing (host network, host PID, host IPC).
  • Require non-root execution and a read-only root filesystem where feasible.
  • Require resource requests and limits.
  • Restrict allowed image registries to your approved Azure Container Registry.
  • Require approved ingress and deny unintended public exposure.

Start in audit mode to measure the blast radius, then move the high-confidence rules to enforce. The same constraint definitions you validate in a pull request and in CI are the ones that run at production admission, one rule, evaluated everywhere.

Why this maps cleanly to compliance

Because each rule is executable and centrally assigned through Azure Policy, it also produces evidence. Azure Policy’s compliance view shows, per assignment, which resources conform and which do not, which becomes an audit-ready record rather than a screenshot collected before a deadline. One well-written control can satisfy an internal standard, a regulatory requirement, and an audit framework simultaneously, the same property that makes policy as code worth the effort anywhere.

The takeaway

On AKS you do not have to choose between Azure-native posture management and open-source policy engines, the Azure Policy add-on gives you both, with Gatekeeper underneath. The decision that matters is moving from detection to enforcement: stop reporting that the door was open and start closing it at admission. Detection tells you what happened. Admission control decides what is allowed to happen.

I write about cloud security, DevSecOps governance, and AI risk, with a focus on enforcement that holds up at scale. Connect with me on LinkedIn.