| 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
-
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.
-
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).
-
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.
-
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.
-
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).
-
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).
-
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.
-
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
