11.1 Containers: AKS, ACR, ACI, Container Apps & Defender for Containers

11.1 Containers: AKS, ACR, ACI, Container Apps & Defender for Containers

Quick Answer: Under Secure compute → Implement security for application platform services, SC-500 expects you to detect misconfigurations and runtime risks with Defender for Containers, then harden AKS, Azure Container Registry (ACR), Azure Container Instances (ACI), and Azure Container Apps. Prefer private control planes, Entra + Azure RBAC, managed identity pulls, network isolation, and admission policies—not long-lived registry passwords.

Containers concentrate risk: one vulnerable image can run at scale; a public API server exposes the control plane; a privileged pod can escape toward the node. SC-500 measures both Defender for Containers and the native security knobs on each Azure container tier.

Where containers run on Azure

All of them commonly pull images from ACR. Compromising the registry or using weak pull credentials undermines every runtime.

Defender for Containers: misconfigurations and runtime risks

Microsoft Defender for Containers is a Defender for Cloud workload protection plan. Microsoft documents five core domains:

1. Security posture management — continuous discovery of clusters, workloads, and misconfigurations; recommendations with remediation guidance; Security Explorer hunting.
2. Vulnerability assessment — agentless scanning of registry images, running containers (where supported), and cluster nodes against Microsoft Defender Vulnerability Management findings.
3. Run-time threat protection — Kubernetes-aware detections (cluster, node, workload) mapped to MITRE ATT&CK for Containers, with investigation paths into Microsoft Defender XDR.
4. Software supply chain protection — associate findings with images; support gated deployment so clusters can audit/block noncompliant images.
5. Deployment and monitoring — detect missing sensors; frictionless scale-out of monitoring components.

Posture vs runtime (exam distinction)

Agentless capabilities use cloud and Kubernetes APIs without a node agent. Sensor-based capabilities (Defender sensor on AKS) add deeper runtime visibility—for example antimalware signals, DNS anomaly detection, binary drift detection/blocking for unauthorized processes, and richer workload telemetry.

Azure Policy for Kubernetes (Gatekeeper under the hood) is the admission-control companion: enforce “no privileged containers,” allowed registries, required labels, and related data-plane hardening before objects persist. Defender surfaces recommendations; Policy can prevent bad future workloads.

Exam trap: Enabling Defender for Containers does not automatically make AKS private or disable the ACR admin user. Defender detects and recommends; you still implement native controls.

AKS security controls

Network and control plane

• Private AKS cluster — Kubernetes API server is not public; access is over private networking (private endpoint patterns). Prefer private clusters for production and regulated workloads.
• Authorized IP ranges — if the API remains public, restrict source IPs (weaker than private, better than open).
• Network policies — use Azure Network Policy, Calico, or Cilium (depending on cluster networking) so pods are not flat-open within the cluster. Default-deny between namespaces is a common design goal.
• Ingress — terminate TLS thoughtfully; place Application Gateway / Front Door WAF in front of internet-facing services (covered in 11.4).

Authentication and authorization

Pair cluster-admin access with PIM (from identity chapters)—standing cluster-admin is an overprivilege anti-pattern.

Workload identity and secrets

Prefer Azure Workload Identity (Kubernetes service account federated to a user-assigned managed identity) so pods obtain Entra tokens without secrets in the cluster. Avoid embedding ACR passwords or storage keys in pod env vars. Pull from ACR with managed identity / AcrPull rather than long-lived imagePullSecrets passwords when the platform supports it.

Pod and data-plane hardening

• Pod Security Admission / restricted policies — reduce privilege escalation and host access.
• Azure Policy for Kubernetes — continuous admission enforcement aligned with CIS/MCSB-style controls.
• Confidential containers — for high-sensitivity processing, know AKS can host confidential node pools (memory encryption / attestation themes) as an advanced control, not a substitute for RBAC and network policy.

Scenario: public API server + Defender alert

Contoso enables Defender for Containers and sees recommendations: API server publicly reachable, privileged containers allowed, images with critical CVEs. Correct layered response:

1. Move to private cluster or at least authorized IP ranges.
2. Enforce Azure Policy denying privileged pods.
3. Remediate image CVEs in ACR; block deployment of unapproved tags.
4. Confirm Defender sensor profile is enabled for runtime coverage.
5. Switch admin access to Entra + Azure RBAC with least privilege.

ACR security

ACR is the supply-chain chokepoint.

Exam trap: “Enable ACR admin for simplicity” is almost always the wrong answer. Use managed identity + AcrPull.

ACI and Azure Container Apps

Azure Container Instances

• Deploy container groups into a delegated subnet for private network placement.
• Use managed identity for ACR pulls and outbound access to Key Vault, Storage, and other PaaS.
• Prefer no public IP when only internal callers should reach the workload.
• Confidential container options exist for memory-isolated workloads on supported hardware.

Azure Container Apps

• Use a Container Apps environment with VNet integration (workload profiles environments) for private networking.
• Set ingress to internal when only VNet/private callers should hit the app; use external ingress only when intentional.
• Apply managed identity for ACR and Azure resources; avoid baking secrets into images.
• Use platform secrets or Key Vault references carefully; managed identity to Key Vault remains the cleaner pattern.
• Layer IP restrictions / authentication at ingress when external.

Defender for Containers still contributes image vulnerability and posture value even when runtime sensor depth differs from full AKS.

Control mapping cheat sheet

SC-500 traps

1. Defender for Containers = only ACR scanning — Also posture and runtime.
2. Kubernetes NetworkPolicy replaces NSG/Firewall — Different layers; cluster microsegmentation does not replace hub perimeter controls.
3. Public AKS + strong passwords is “secure enough” — Control plane exposure is still critical risk.
4. imagePullSecrets with admin credentials “for automation” — Prefer managed identity.
5. Confusing Container Apps with AKS — Different control surfaces; do not invent kubectl-only answers for Container Apps.

Engineer checklist

1. Enable Defender for Containers on the subscription; remediate high-severity recommendations.
2. Prefer private AKS; enforce Entra + Azure RBAC for Kubernetes.
3. Deploy network policies and Azure Policy for Kubernetes admission rules.
4. Harden ACR: admin off, private network, soft delete/signing as required, RBAC least privilege.
5. Standardize workload identity and managed identity pulls.
6. For ACI/Container Apps: VNet + internal ingress + managed identity.
7. Route internet-facing HTTP through WAF (section 11.4) and monitor runtime alerts in Defender XDR.

Bottom line: SC-500 container security is a chain—secure the image, lock the registry, privatize and authorize the control plane, constrain the pod network, and let Defender for Containers catch what configuration misses at runtime.