Defender for Containers: AKS, ACR, ACI, Container Apps…

One Defender plan, four compute tiers

Simple explanation

Containers on Azure can run in four different places: Azure Kubernetes Service (AKS), Azure Container Apps, Azure Container Instances (ACI), and via container support in App Service. They all pull images from Azure Container Registry (ACR).

Microsoft Defender for Containers is the single Defender for Cloud plan that protects the container surface across all of these. It does three things:

Scans container images in ACR for vulnerabilities — before they’re pulled, and continuously as new CVEs are disclosed.
Scans the runtime in AKS clusters for behavioural threats — suspicious processes inside containers, anomalous Kubernetes API calls, sensitive volume mounts, lateral movement signals.
Hardens posture — Kubernetes admission control via Azure Policy (with Gatekeeper under the hood), CIS benchmark and Microsoft Cloud Security Benchmark recommendations, secret-scanning of images.

Plus each compute tier has its own native security controls — RBAC, network isolation, identity, image signing — that you must know how to configure.

Defender for Containers — coverage at a glance

Defender for Containers coverage across the four Azure container compute surfaces
Defender capability	AKS	Container Apps	ACI	ACR
Vulnerability scanning of images	✓ (via ACR)	✓ (via ACR)	✓ (via ACR)	✓ direct
Runtime threat detection (in-cluster)	✓ (Defender sensor on nodes)	Limited — platform managed; runtime detection is more about anomalous control plane events	Limited	N/A (not a runtime)
Kubernetes admission control via Azure Policy	✓	N/A	N/A	N/A
Hardening recommendations (CIS + MCSB)	✓	✓	✓	✓
Secrets scanning of image layers	✓	✓	✓	✓
Defender XDR integration	✓	✓	✓	✓

Azure Kubernetes Service (AKS) security controls

AKS-specific SC-500 surfaces:

Authentication: Microsoft Entra ID integration for the cluster’s API. Two patterns:
- Entra integration (legacy) — the cluster uses Entra users/groups for kubectl auth via a kubelogin plugin.
- Entra integration with Azure RBAC for Kubernetes Authorisation — both authentication AND authorisation flow through Microsoft Entra + Azure RBAC. The modern default.
Authorisation: Azure RBAC for Kubernetes Authorization replaces Kubernetes RBAC for cluster-scoped and namespace-scoped operations. Built-in roles: Azure Kubernetes Service RBAC Reader, ... Writer, ... Admin, ... Cluster Admin.
Network: control plane public/private (private cluster — control plane reached over Private Endpoint), node pool networking (Azure CNI / Overlay / Kubenet), Cilium for advanced network policy, ingress via Application Gateway for Containers / AGIC / managed NGINX.
Workload identity: federation between Kubernetes service accounts and Entra ID user-assigned managed identities (covered in identity module 4). Replaces the legacy “pod-managed identity” path.
Pod security: Pod Security Admission (the Kubernetes built-in), Azure Policy for Kubernetes admission rules, Defender sensor for runtime detection.
Confidential containers: AKS supports confidential container node pools on AMD SEV-SNP and Intel TDX, with workload attestation.

Azure Container Registry (ACR) security controls

Authentication: Microsoft Entra ID (token via az acr login or pull-from-compute managed identity), repository-scoped tokens for fine-grained CI/CD, admin user disabled (the SC-500 right answer when admin user is mentioned).
Network: ACR firewall (allow selected VNets and IPs), Private Endpoint for VNet-only access, trusted Azure services exception.
Content trust / signing: image signing via Notation (and Notary v2) for supply-chain integrity; combined with admission-time signature verification on AKS.
Encryption: encryption at rest with platform or customer-managed keys (CMK).
Geo-replication: replicates the registry to multiple regions; available on Premium SKU.
Defender integration: Defender for Containers scans ACR images on push, on pull (over the last 30 days), and continuously against MDVM.

Azure Container Instances (ACI) security controls

Authentication to ACR: managed identity is the right pattern (replaces imagePullSecrets with credentials).
Network: deploy ACI into a delegated subnet for VNet integration.
Identity: ACI supports system-assigned and user-assigned managed identities for the container’s outbound auth.
Confidential containers: ACI supports confidential containers on AMD SEV-SNP for memory-encrypted workloads.

Azure Container Apps security controls

Identity: managed identities for both the container app’s outbound auth and ACR image pulls.
Network: deploy into a Container Apps environment with VNet integration (workload profiles environment); internal-only ingress (no public IP).
Ingress: managed certificates, custom domain bindings, IP restrictions, mTLS between apps within the environment.
Secrets: native secrets store with optional Key Vault references — but managed identity to read directly from Key Vault is the cleaner SC-500 pattern.
Defender integration: image vulnerability scanning via ACR; CSPM and hardening recommendations apply.

The 'admin user enabled on ACR' trap

ACR has an “admin user” capability — a built-in username/password that can pull and push to the registry. It exists for legacy compatibility with tools that require basic auth.

SC-500 questions that mention admin user enabled are almost always pointing at a remediation: disable the admin user, switch the consuming compute to managed-identity-based auth on the appropriate AcrPull (or AcrPush) RBAC role on the registry.

This is the same managed-identity-vs-stored-credential pattern from Domain 1, applied to ACR specifically. The right answer is always managed identity + RBAC.

Scenario: Ravi hardens Maple Genomics’ AKS workloads

Maple Genomics runs Foundry-adjacent workloads (image preprocessing, vector indexers, batch pipelines) on AKS. Ravi’s hardening pass:

AKS: rotate to Entra integration with Azure RBAC for Kubernetes Authorisation. Cluster is a private cluster (control plane on Private Endpoint).
Identity: workload identity federation across all pods — service accounts federate to user-assigned managed identities; no stored secrets in the cluster.
Network: Azure CNI Overlay, Cilium for network policy, Application Gateway for Containers for ingress with WAF in front.
Image source: single ACR (Premium, geo-replicated), admin user disabled, public access disabled, Private Endpoint only. Image signing with Notation; AKS admission policy requires signed images.
Defender for Containers Plan: enabled on the subscription. Defender sensor deployed to all AKS node pools. ACR vulnerability scanning on push, pull, continuous.
Azure Policy for Kubernetes: built-in initiative Kubernetes cluster pods should only use approved host network and port range + custom Gatekeeper policy disallowing privileged: true containers.
Confidential containers: a dedicated confidential-container node pool for the patient-data preprocessing workload (memory-encrypted AMD SEV-SNP).

After: zero standing AKS admin access (everything via Entra + RBAC + PIM), zero credentials in the cluster (workload identity federation), zero unsigned images admitted, runtime threats surfaced to Defender XDR, posture continuously scored against CIS + MCSB.