defender-for-containers

name	defender-for-containers
description	Guidance for Microsoft Defender for Containers — Kubernetes and container security across AKS, Azure Arc-enabled Kubernetes, EKS, GKE, and OpenShift. Covers agentless discovery, agentless vulnerability assessment for images and running containers (powered by Microsoft Defender Vulnerability Management), runtime threat detection via the Defender sensor (eBPF on Linux), Kubernetes data plane hardening with Azure Policy / Gatekeeper, registry scanning for ACR / ECR / GAR, admission control, attack path analysis, and Sentinel integration. WHEN: Defender for Containers, AKS security, container runtime threat detection, Kubernetes admission control, image vulnerability scanning, ACR scan, EKS GKE security in Defender for Cloud, K8s posture, container attack path, Defender container sensor, Gatekeeper Azure Policy AKS, agentless container scan. DO NOT USE for VM/host hardening (use defender-for-servers), AKS networking design (use azure-network-security-design), or general AKS day-2 ops unrelated to security.
license	MIT
metadata	{"author":"Microsoft","version":"0.1.0"}

Microsoft Defender for Containers

Defender for Containers is the Kubernetes-aware plan in Microsoft Defender for Cloud. It covers AKS, Azure Arc-enabled Kubernetes (on-prem, EKS, GKE, OpenShift), and the container registries that feed them, providing posture, image vulnerability assessment, runtime threat detection, and admission control.

When to use

Securing Kubernetes clusters and the registries that supply them. Use this skill for plan rollout, sensor vs agentless trade-offs, registry scanning, admission policy design, and runtime alert response.

Do not use this skill for VM/host hardening (defender-for-servers), cluster networking design (azure-network-security-design), or generic AKS operations (azure-kubernetes).

Capability map

Capability	How it works	Coverage
Agentless discovery	API-based cluster inventory, control-plane misconfig, K8s API audit log analytics	AKS, EKS, GKE, Arc
Agentless vulnerability assessment	Snapshots node disks; scans images in registries and running containers	AKS, EKS, GKE
Registry scanning	Pull-time, push-time, and continuous scan of images	ACR, ECR, GAR
Runtime threat detection	Defender sensor (DaemonSet, eBPF on Linux) — fileless, lateral movement, crypto-miner detections	AKS, Arc, EKS, GKE
Kubernetes data plane hardening	Azure Policy add-on (OPA/Gatekeeper)	AKS, Arc-enabled K8s
Attack path analysis	Combines posture + vuln + runtime to surface internet → pod → cloud-IAM paths	All

Approach

1. Enable Defender for Containers at subscription scope. Auto-provisioning installs:

   • Defender sensor (DaemonSet) for runtime detection on Linux nodes.
   • Azure Policy for Kubernetes add-on for admission control.
   • Connects ACR scanning automatically. Verify: kubectl get ds -n kube-system shows microsoft-defender-collector-ds; AKS shows Defender profile = enabled.

2. Connect non-Azure clusters via Arc. EKS/GKE need a connector at the AWS/GCP cloud account level + Arc onboarding for runtime sensor (agentless features work without sensor).

3. Registry scanning posture. Turn on continuous scanning so newly-disclosed CVEs raise findings on already-pushed images, not just at push time. Set retention so you can answer "is image X vulnerable to CVE-Y" 90 days later.

4. Image vuln management at the pipeline. Don't wait for runtime: integrate the same MDVM API into CI to fail builds on critical, exploitable CVEs. Pair with image signing (Notation / cosign) and admission control to require signed images.

5. Runtime threat detection — sensor or agentless?

   • Sensor required for: fileless attacks, process tree, in-memory exploitation, lateral movement, reverse shell.
   • Agentless covers: image vuln, posture, K8s API audit-based detections.
   • Use both in production. Sensor only on Linux node pools (Windows runtime sensor coverage is limited).

6. Admission control with Azure Policy / Gatekeeper. Roll out as audit for 14 days, then deny. Baseline policies:

   • No privileged containers.
   • No hostPath mounts to sensitive paths.
   • Required readOnlyRootFilesystem for app workloads.
   • Required resource limits.
   • Required signed images (allowlist registries).

7. Attack path analysis — review weekly. The high-value paths to fix first are internet-exposed pod with critical CVE → workload identity → cloud IAM. Prioritise by blast radius, not finding count.

8. Stream alerts to Sentinel via the Defender for Cloud connector. Build hunting queries on SecurityAlert filtered to ProductName = "Microsoft Defender for Containers".

Guardrails

• Defender sensor is required for runtime detection. Agentless alone won't catch reverse shells or crypto miners running inside pods.
• Roll admission policies in audit first. A requiredLabels policy in deny mode on day one will brick deployments.
• Don't run two privileged DaemonSets that hook the kernel (e.g., Defender sensor + Falco + a third-party EDR) without testing — eBPF program collisions and node instability.
• ACR + private endpoint + Defender scanning needs careful network design. The scanner must reach the registry; verify private DNS resolution and trusted-services bypass.
• Don't scope plan to a single cluster's RG. New clusters in other RGs go unprotected. Subscription scope + policy enforcement.
• Windows containers have limited sensor coverage. Compensate with stricter admission control and image scanning for Windows workloads.
• Image vuln findings without exploitability context are noise. Always filter by exploitable / KEV before triage.

Common anti-patterns

• "Agentless only because the sensor adds 80 MB of RAM per node" — and you have no runtime detection. Budget the RAM.
• "Admission policy in deny on day one" — outage. 14-day audit, fix violations, then deny.
• "Image scanning at push only" — tomorrow's CVE on yesterday's image goes unflagged. Continuous scanning on.
• "CI ignores MDVM findings — we'll catch it at runtime" — vulnerabilities reach prod; rollback is expensive. Fail the build on critical exploitable.
• "All clusters in scope, no exemptions for sandbox" — alert volume buries real incidents. Tag/scope sandbox out of admission deny + alert routing.
• "Used Defender for Containers for VM hosts running Docker directly" — wrong tool; that's a defender-for-servers scenario.
• "Skipped Arc for EKS/GKE because connector is enough" — no runtime sensor, no eBPF detections.

Example prompts

• Enable Defender for Containers across 5 subs with AKS clusters; pilot on dev for 7 days.
• Roll out Azure Policy for Kubernetes admission control — baseline policy set in audit.
• Connect 3 EKS clusters via Arc and enable runtime sensor.
• Build a CI gate that fails on critical exploitable CVEs from MDVM.
• Investigate a "Crypto-mining activity in container" alert — runbook + KQL.
• Tune attack path analysis to surface only internet-to-cloud-IAM paths.
• Design admission control to require signed images from approved ACRs only.

Microsoft Learn

• Overview: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction
• Enable plan: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable
• Architecture: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-architecture
• Vulnerability assessment: https://learn.microsoft.com/azure/defender-for-cloud/agentless-vulnerability-assessment-azure
• Runtime detection alerts: https://learn.microsoft.com/azure/defender-for-cloud/alerts-reference#alerts-k8scluster
• Azure Policy for Kubernetes: https://learn.microsoft.com/azure/governance/policy/concepts/policy-for-kubernetes
• EKS / GKE protection: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-eks
• Attack path analysis: https://learn.microsoft.com/azure/defender-for-cloud/concept-attack-path