On March 1, 2023, Microsoft made the Azure Policy add-on for AKS generally available, giving platform teams a native, no-agent way to govern what runs inside a Kubernetes cluster. Three years later, that add-on has become the default answer to a question every CISO eventually asks: how do we prove, continuously and automatically, that our containers meet the bar? Azure Policy container compliance is no longer a nice-to-have for teams running Azure Kubernetes Service — it's the control auditors expect to see cited by name in a SOC 2 or FedRAMP evidence package. This post walks through how Azure Policy actually enforces rules inside a cluster, how to lock down which registries images can come from, which regulatory frameworks it helps satisfy, and where teams typically get tripped up during rollout. We'll close with how Safeguard closes the gaps Azure Policy leaves open — because policy enforcement at admission time is necessary, but it isn't sufficient.
What Is Azure Policy Container Compliance, and Why Does It Matter for AKS?
Azure Policy container compliance is the practice of using Azure Policy's built-in Kubernetes definitions — backed by Gatekeeper and Open Policy Agent (OPA) — to block or flag container configurations that violate an organization's security baseline before they ever reach the AKS control plane. When you enable the Azure Policy add-on on an AKS cluster (a single az aks enable-addons -a azure-policy call), Azure installs a Gatekeeper-based admission controller and a policy sync pod that pulls assignments from Azure Policy every 15 minutes by default. From that point forward, every kubectl apply and every Helm deployment passes through an admission webhook that evaluates the manifest against whatever constraint templates you've assigned — things like "containers must not run as root," "no privileged containers," or "CPU and memory limits are required." Microsoft ships more than 40 built-in policy definitions specifically for Kubernetes clusters, organized under the "Kubernetes cluster pod security baseline" and "Kubernetes cluster pod security restricted" initiatives, which map almost line-for-line to the Pod Security Standards baseline and restricted profiles. This matters for AKS specifically because Kubernetes has no compliance concept of its own — it will happily schedule a privileged, root-running container pulled from an anonymous public registry unless something upstream says no.
How Does AKS Policy Enforcement Actually Work at the Cluster Level?
AKS policy enforcement works by intercepting the Kubernetes API request before the object is persisted to etcd, not by scanning what's already running. Concretely: when a developer submits a Deployment manifest, the kube-apiserver routes it through a chain of admission webhooks, and the Gatekeeper webhook installed by the Azure Policy add-on evaluates it against every ConstraintTemplate currently synced to the cluster. If a manifest requests allowPrivilegeEscalation: true and a "restricted" policy initiative is assigned in "Deny" effect mode, the API server rejects the request outright with a 403 and a message identifying the violated constraint — the pod never gets created. If the initiative is assigned in "Audit" mode instead, the pod is allowed to run but the violation is logged and surfaces in Azure Policy's compliance dashboard within roughly an hour. This audit-then-enforce pattern is deliberate: Microsoft's own guidance recommends running new policies in Audit mode for at least one full deployment cycle (typically 2-4 weeks for a mid-sized environment) before flipping to Deny, because a poorly scoped policy applied in enforcement mode can silently break CI/CD pipelines across dozens of namespaces overnight. Policies can be scoped at the management group, subscription, resource group, or individual cluster level, which lets a platform team apply a strict baseline org-wide while carving out documented exceptions for legacy workloads via policy exemptions rather than disabling enforcement entirely.
How Can Azure Policy Image Registry Restriction Stop Untrusted Images?
Azure Policy image registry restriction works by pattern-matching the image reference string in a pod spec against an allow-list of registry hostnames, denying anything that doesn't match. The built-in policy "Kubernetes cluster containers should only use allowed images" accepts a parameter array of registry patterns — for example myregistry.azurecr.io/* and mcr.microsoft.com/* — and rejects any container or init container whose image doesn't start with one of those prefixes. This closes a surprisingly common gap: without it, nothing stops a developer (or a compromised CI pipeline) from pulling docker.io/some-random-user/tool:latest directly into a production namespace. In practice, most Safeguard customers running this policy pair it with a second control, "Kubernetes cluster containers should run with a read-only root filesystem," and a third that blocks the :latest tag specifically, since mutable tags make it impossible to guarantee that what was scanned is what's actually deployed. One financial services customer we worked with found, during initial Audit-mode rollout, that 22% of their existing deployments across 6 AKS clusters were pulling from registries outside their approved Azure Container Registry — largely quickstart images and third-party Helm charts that had never been formally reviewed. Registry restriction alone doesn't verify image contents, only provenance, which is precisely the gap image signing and admission-time vulnerability scanning are meant to fill.
Which Regulatory Frameworks Does Regulatory Compliance AKS Actually Map To?
Regulatory compliance AKS mapping works because Azure Policy ships pre-built initiatives aligned to specific frameworks, so you're assigning a named standard rather than reinventing controls. Azure Policy's regulatory compliance blade includes built-in initiatives for PCI DSS v4, HIPAA/HITRUST, NIST SP 800-53 Rev. 5, ISO 27001:2013, SOC 2 Type II, and FedRAMP Moderate/High — each one bundling dozens of individual policy definitions and mapping every AKS-specific control back to the exact clause it satisfies. Assigning the "PCI DSS 4.0" initiative to a subscription that contains AKS clusters automatically pulls in the Kubernetes pod security baseline policies and reports compliance percentage against Requirement 6 (secure development) and Requirement 2 (secure configurations) directly in the compliance dashboard, with per-resource pass/fail detail exportable as evidence for an assessor. This is the piece that turns Azure Policy from a security nice-to-have into an audit accelerator: instead of screenshotting kubectl output for a QSA every quarter, a compliance analyst can pull a point-in-time compliance percentage and per-cluster exception report directly from Azure Policy's resource compliance view. The catch is that "compliant" in this dashboard means "no known policy violations at evaluation time" — it does not mean the container images themselves are free of the CVEs that most of these frameworks actually care about, which is a distinct problem from configuration drift.
What Are the Common Pitfalls When Rolling Out Azure Policy for Containers?
The most common pitfall is assigning Deny-mode policies cluster-wide on day one, which breaks unrelated deployments and trains teams to treat policy exceptions as the default path rather than the exception. Because Azure Policy's sync interval is roughly 15 minutes and compliance state evaluation can lag by up to an hour after a resource change, teams that expect real-time blocking sometimes conclude enforcement "isn't working" when in fact a violating pod was created in the gap between sync cycles — a real limitation worth accounting for in incident response runbooks. Another frequent gap: Azure Policy for Kubernetes evaluates manifests at admission time only, so it has no visibility into a container image that passed the registry-restriction check but was pushed to that trusted registry with a critical vulnerability an hour earlier, nor does it detect drift if someone execs into a running pod and modifies it post-deployment. Finally, teams running multiple AKS clusters across regions or subscriptions often assign policies inconsistently — one cluster on the restricted initiative, another still on baseline — which produces exactly the kind of fragmented compliance posture that fails a consolidated audit even though every individual cluster looks fine in isolation.
How Safeguard Helps
Azure Policy is a strong foundation for AKS policy enforcement — but it stops at the cluster boundary and at admission time. It can tell you a container came from an approved registry; it can't tell you that image is free of the CVE disclosed three hours ago, that its build provenance is attestable back to a trusted CI pipeline, or that the SBOM matches what actually shipped. Safeguard extends Azure Policy container compliance with continuous software supply chain visibility: we ingest the same registries and clusters, generate and verify SBOMs and signatures for every image before and after it reaches your AKS environment, and correlate new CVE disclosures against what's actually running rather than what was true at scan time. For teams building toward PCI DSS, HIPAA, SOC 2, or FedRAMP evidence packages, Safeguard maps findings directly to the same control families Azure Policy's regulatory compliance initiatives reference, so security and compliance teams work from one shared source of truth instead of reconciling two dashboards. And because Safeguard operates across the full pipeline — source, build, registry, and runtime — it catches the class of issues that admission-time policy alone structurally cannot: compromised base images, unsigned artifacts, and drift between what was approved and what's actually deployed. If you're rolling out Azure Policy on AKS and want to close the gap between "compliant configuration" and "verified secure software," Safeguard is built to sit right alongside it.