Azure Policy and Governance Guardrails

Why this matters

Gatekeeper (module 04) enforced rules inside one cluster. But your risks don't stop at the cluster boundary — an unencrypted storage account, a public IP on a database, a VM with no disk encryption, a resource in a non-approved region are all misconfigurations at the Azure control plane, below Kubernetes entirely. Azure Policy is admission control for Azure itself: it evaluates and can block or auto-remediate resource configurations across whole subscriptions, using the exact same audit-then-enforce discipline you just learned. And its AKS integration is literally Gatekeeper under the hood — so this module is both a new layer (the cloud) and a managed wrapper around a tool you already understand. This is a light preview of governance-at-scale; track 17 owns the multi-subscription, landing-zone version.

Concepts

Azure Policy is admission control for the cloud control plane

Every concept from module 04 maps almost one-to-one onto Azure:

When you create or update an Azure resource, the Resource Manager checks it against every policy assigned to its scope before persisting it — the same admission model, just at the Azure API instead of the Kubernetes API. You already understand the mental model; this is applying it one layer down (or up, depending how you look at it).

Built-in definitions vs. custom

Azure ships hundreds of built-in policy definitions for common governance needs — "storage accounts should disable public blob access", "allowed locations", "AKS clusters should not allow privileged containers". You mostly assign built-ins rather than write your own; writing a custom definition (JSON with a policyRule of if/then) is possible but rarely needed early. This is a deliberate contrast with Gatekeeper, where you wrote the Rego yourself — Azure's library means governance is often assembly, not authoring.

Effects: Audit, Deny, DeployIfNotExists, and friends

A policy's effect is what it does when a resource matches its condition — the Azure analog of Gatekeeper's enforcement action, but richer:

• Audit — allow the resource but mark it non-compliant for reporting. The observe-only mode; the Azure equivalent of dryrun. Always start here.
• Deny — reject the create/update outright (the hard guardrail). The Azure equivalent of Gatekeeper deny.
• DeployIfNotExists (DINE) — the one with no Gatekeeper equivalent: if a required related resource/config is missing, Azure automatically deploys it (e.g. "if a subnet has no NSG, deploy one"; "enable diagnostic settings if absent"). This is remediation, not just prevention — Azure fixes drift for you. DINE assignments run under a managed identity you grant permissions to, since they write resources.
• AuditIfNotExists, Modify, Disabled — audit-a-related-resource, alter-a-property-on-write, and turn-a-policy-off respectively.

The effect you choose determines whether a policy reports, blocks, or fixes — the single most important field on any assignment.

Assignments, scope, and the compliance loop

A policy assignment applies a definition (or initiative) to a scope: a management group, a subscription, or a resource group. Scope determines blast radius — assign at subscription level and every resource group inherits it (the same inheritance you saw with az role assignment list --all in module 00). After assignment, Azure runs a compliance evaluation (on a schedule, and on resource changes) and reports each resource as Compliant or Non- compliant — your cluster-wide "what's the state right now" view, exactly like Gatekeeper's audit but for all Azure resources in scope. Note the timing: a new assignment can take a while (up to ~30 minutes) to show initial compliance results, and Deny only applies to future create/update — it never deletes existing non-compliant resources, only reports them.

Initiatives (policy sets): bundling policies into a standard

Enforcing a security standard usually means many related policies. An initiative (a.k.a. policy set) bundles a group of definitions under one assignable unit with shared parameters — assign the whole thing once instead of dozens of policies individually. Azure ships large built-in initiatives (e.g. the Azure Security Benchmark / Microsoft Cloud Security Benchmark, CIS, regulatory compliance sets). This is the building block track 17 scales up to management-group-wide governance; here you just meet the concept and assign a small one.

Azure Policy for AKS = managed Gatekeeper

This is the payoff for module 04. Azure Policy has an AKS add-on that installs Gatekeeper into your cluster and translates a set of built-in Azure policy definitions into Gatekeeper ConstraintTemplates/Constraints automatically. So policies like "Kubernetes cluster should not allow privileged containers" or "should not allow the latest image tag" are enforced by Gatekeeper in the cluster, but managed and reported through Azure Policy — giving you one compliance dashboard across many clusters instead of running raw Gatekeeper on each. Everything you learned in module 04 about audit-before-deny and exemptions still applies; Azure just wraps it. This is the shared-responsibility trade-off (module 00) again: less to operate, at the cost of Azure's opinionated built-in set.

Command reference

Flag breakdown for az policy assignment create --name deny-public-blob --policy <definition-id> --scope /subscriptions/<sub>/resourceGroups/rg-sec-lab --params '{"effect":{"value":"Audit"}}':

• --name deny-public-blob — a name for this assignment (how you find/delete it later).
• --policy <definition-id> — the definition (built-in or custom) being assigned; for an initiative you'd use --policy-set-definition instead.
• --scope .../resourceGroups/rg-sec-lab — the blast radius; scoping to one resource group keeps a lab contained rather than hitting the whole subscription.
• --params '{"effect":{"value":"Audit"}}' — overrides the definition's effect parameter to Audit (report-only) for a safe first pass; you'd change it to Deny after reviewing compliance. Not every definition exposes effect as a parameter — some hardcode it.

Flag breakdown for az aks enable-addons -g rg-aks-learn -n aks-learn -a azure-policy:

• enable-addons -a azure-policy — installs the Azure Policy add-on, which deploys Gatekeeper into the cluster and syncs Azure-managed policies down as Constraints.
• After this, AKS-scoped built-in policies you assign are enforced by Gatekeeper but reported in Azure Policy compliance — the managed-Gatekeeper model from Concepts.

Hands-on exercises

These use real Azure. Policy assignments are free; the AKS add-on runs Gatekeeper Pods on your existing cluster (small cost while the cluster runs). Scope everything to a throwaway resource group and clean up. Reuse rg-aks-learn/aks-learn from track 07 where noted.

1. (Azure) Create a lab resource group and browse built-ins.

   az group create --name rg-sec-lab --location eastus
   az policy definition list --query "[?policyType=='BuiltIn' && contains(displayName,'Storage account')].{name:name, display:displayName}" -o table | head
   

   Expect a list of built-in storage-related policies — governance you can assign without authoring anything.

2. (Azure) Assign a Deny policy: no public blob storage, in Audit mode first. Find the "Storage accounts should prevent public access"–style built-in and assign it as Audit:

   DEF=$(az policy definition list --query "[?policyType=='BuiltIn' && displayName=='Storage account public access should be disallowed'].name" -o tsv)
   az policy assignment create --name audit-public-blob \
     --policy "$DEF" \
     --scope $(az group show -n rg-sec-lab --query id -o tsv) \
     --params '{"effect":{"value":"Audit"}}'
   

   (If that exact display name isn't found, pick any built-in with an effect parameter and adapt.) Expect the assignment to be created. Audit-first is the module-04 discipline applied to Azure.

3. (Azure) Create a resource that violates it and watch compliance.

   az storage account create --name secpubtest$RANDOM --resource-group rg-sec-lab --allow-blob-public-access true --sku Standard_LRS 2>/dev/null || echo "created (or name taken; retry)"
   # compliance is not instant — wait, then:
   az policy state summarize --resource-group rg-sec-lab -o table
   

   Expect (after the evaluation delay, up to ~30 min) the storage account to show as Non-compliant — reported, not blocked, because you assigned Audit. This is the difference between Audit and Deny made concrete.

4. (Azure) Flip the same policy to Deny and prove it blocks. Update the assignment's effect to Deny:

   az policy assignment update --name audit-public-blob \
     --scope $(az group show -n rg-sec-lab --query id -o tsv) \
     --params '{"effect":{"value":"Deny"}}'
   # (allow a few minutes for the effect change to take hold, then:)
   az storage account create --name secdeny$RANDOM --resource-group rg-sec-lab --allow-blob-public-access true --sku Standard_LRS
   

   Expect the create to be rejected by Azure Policy (a RequestDisallowed /policy-violation error). Note it did not delete the non-compliant account from exercise 3 — Deny only stops new/updated resources; existing drift is reported, not auto-removed.

5. (Azure) Explore an initiative (policy set).

   az policy set-definition list --query "[?policyType=='BuiltIn'].displayName" -o tsv | grep -i benchmark | head
   

   Expect the Microsoft Cloud Security Benchmark (and others) listed — a bundle of many definitions assignable as one unit. Don't assign it to a real subscription in a lab (it's broad); just observe that governance standards ship as initiatives, the unit track 17 scales up.

6. (Azure/AKS) Enable Azure Policy for AKS — managed Gatekeeper. On your track-07 cluster:

   az aks enable-addons -g rg-aks-learn -n aks-learn -a azure-policy
   kubectl get pods -n gatekeeper-system
   kubectl get constrainttemplates | head
   

   Expect Gatekeeper Pods running and Azure-managed ConstraintTemplates present — Azure installed and populated Gatekeeper for you. Compare directly to module 04, where you installed and wrote all of it by hand: same engine, managed wrapper.

7. Diagnose and fix: an assignment that "isn't working." Assign an AKS-scoped built-in (e.g. "Kubernetes cluster should not allow privileged containers") in Audit and observe it reports nothing even though you have a privileged Pod. Two common causes to walk: (a) compliance hasn't evaluated yet — Azure Policy for AKS syncs and evaluates on an interval, so wait and re-check az policy state list; (b) the assignment's scope doesn't actually cover the cluster's resource group. Diagnose by confirming scope:

   az policy assignment list --scope $(az aks show -g rg-aks-learn -n aks-learn --query id -o tsv) -o table
   az policy state list --resource $(az aks show -g rg-aks-learn -n aks-learn --query id -o tsv) -o table
   

   Fix by assigning at the correct scope (the cluster's resource group or subscription) and waiting for the evaluation cycle. The lesson mirrors module 04's "audit results aren't instant" — Azure's cycle is longer (minutes to tens of minutes), and "no results yet" is usually timing or scope, not a broken policy.

8. (Azure) Clean up.

   az policy assignment delete --name audit-public-blob --scope $(az group show -n rg-sec-lab --query id -o tsv) 2>/dev/null; true
   az group delete --name rg-sec-lab --yes --no-wait
   # Optionally remove the AKS add-on if you don't want managed Gatekeeper running:
   # az aks disable-addons -g rg-aks-learn -n aks-learn -a azure-policy
   

   Expect the lab RG (and its non-compliant storage account) to be deleted.

Independent challenge

No commands given — build it yourself using this module plus module 04 (audit- then-enforce, exemptions) and module 00 (shared responsibility, risk). Choose one real, defensible governance guardrail for an Azure environment — for example "all resources must be deployed only in approved regions", "storage accounts must not allow public access", or "AKS clusters must not run privileged containers" — and take it from idea to enforced control the disciplined way. Assign the appropriate built-in definition scoped to a lab resource group in Audit, create a violating resource, and confirm it's reported Non-compliant. Then promote the effect to Deny, prove a new violation is blocked, and articulate why the previously-created non-compliant resource is still reported but not removed. Finally, explain in two or three sentences how this Azure-control-plane guardrail complements — rather than duplicates — the in-cluster Gatekeeper policy you wrote in module 04, referring to which layer of your module-00 data-flow diagram each one protects.

Common mistakes & troubleshooting

• Assigning Deny first and causing failed deployments. Start every guardrail in Audit, review compliance, then promote to Deny — the same audit-then-enforce rule as Gatekeeper. A Deny you didn't measure can break legitimate provisioning across a whole scope.
• Expecting Deny to clean up existing resources. It only blocks new/updated resources; pre-existing non-compliant ones are reported, not deleted. Remediating existing drift needs DeployIfNotExists/Modify with a remediation task, or manual fixes.
• Panicking when compliance shows nothing immediately. Evaluation runs on a schedule (and can take up to ~30 minutes for a new assignment) — "no results yet" is usually timing, not a broken policy. Trigger/await evaluation before concluding.
• Wrong scope. A policy assigned to the wrong resource group or subscription simply doesn't see the resources you expect. Confirm the assignment scope actually contains the target resource.
• Forgetting DINE needs a managed identity with permissions. A DeployIfNotExists assignment writes resources, so it runs as a managed identity that must be granted the right role, or remediation silently fails.
• Assuming the AKS add-on enforces everything instantly. It's Gatekeeper underneath with an Azure sync loop — Constraints and compliance take a cycle to propagate, and audit-before-deny still applies.
• Treating Azure Policy and Gatekeeper as interchangeable. They guard different boundaries (cloud control plane vs. Kubernetes API). You generally want both; neither sees what the other governs unless the AKS add-on bridges them.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Cumulative review

Closed-book. Don't reopen earlier modules while attempting these — the point is to find out what actually stuck. These mix modules 00-05 of this track with the baseline from tracks 02/03/07.

1. You now have four admission/enforcement layers: image scanning gate (module 01), Pod Security Admission (03), Gatekeeper (04), and Azure Policy (05). For each, state where in the request path it acts and one thing it catches that the others cannot.
2. Trace a single misconfiguration — "someone deploys a privileged container built from an unscanned :latest image into a prod namespace" — and name, in order, every control across modules 01-05 that could stop it and at which stage each would fire.
3. Explain the audit-then-enforce pattern and show it appearing in three different tools across this track, naming the specific "audit" and "enforce" settings in each.
4. A legitimate infra workload must run privileged and pull from a non-ACR registry. Describe how you'd grant a narrow, reviewable exception at both the Gatekeeper layer (04) and the Pod Security Admission layer (03) without disabling either control cluster-wide.
5. Using module 00's shared-responsibility model, classify each as "Azure secures it" or "you secure it": the AKS control plane is patched; a Pod runs privileged; a storage account allows public blobs; the Gatekeeper add-on is installed. Then say which single tool from this track most directly governs each you-owned item.
6. Compare how a rule is authored in Gatekeeper (04) versus Azure Policy (05) — where you write logic yourself versus assemble built-ins — and explain the shared-responsibility trade-off that difference represents.
7. A secret leaked into a CI log (module 02) and, separately, a :latest-tagged image reached prod (modules 01/04). Both are "a rule wasn't enforced." Describe the specific preventive control from this track for each and why a wiki policy would have failed where policy-as-code succeeds.
8. Your Azure Policy Deny for "no public storage" is active, yet a public storage account still exists. Give two distinct, correct explanations and how you'd tell them apart.
9. Explain why enforcing restricted Pod Security (03) plus a Gatekeeper allowed-registry policy (04) plus a scanned image (01) is genuinely defense-in-depth (module 00) rather than three redundant checks — describe a failure of any one that the other two would still catch something from.
10. You want one compliance dashboard across three AKS clusters instead of running raw Gatekeeper on each. Which module-05 capability gives you that, what does it install, and what module-04 knowledge still applies to operating it safely?

Next

Continue to 06-network-security-in-depth — you've governed what runs; now defend how it talks, layering NSGs, firewall, NetworkPolicy, and mesh mTLS into real defense in depth.