4.3.1. Defender for Containers, AKS, and Container Registry Security
💡 First Principle: Container security spans three distinct concerns that map to three distinct moments in a container's life — what's inside the image before it ever runs (registry), how the cluster is configured to run it (AKS), and whether its actual runtime behavior looks safe (Defender for Containers) — and a control addressing one doesn't cover the other two.
Defender for Containers detects misconfigurations and runtime risks — vulnerable images, risky runtime behavior, exposed Kubernetes API servers — across containerized workloads. Azure Kubernetes Service (AKS) security controls include RBAC integration with Microsoft Entra ID, network policies restricting pod-to-pod traffic, and private cluster configuration to keep the API server off the public internet. Azure Container Registry security controls cover image scanning for known vulnerabilities before deployment, access control over who can push and pull images, and content trust for image signing.
⚠️ Exam Trap: A vulnerability found by Container Registry scanning and a runtime risk flagged by Defender for Containers address different points in the container lifecycle — a scenario asking "how would you catch this before it ever deploys" points to registry-level scanning, while "how would you catch this while it's actively running" points to Defender for Containers.
Reflection Question: Why would a container image that passed registry vulnerability scanning still need runtime monitoring through Defender for Containers after deployment?
