Container Security and Kubernetes Threat Detection

Container security encompasses the practices and tools used to protect containerized applications throughout their lifecycle: from image creation and registry storage to deployment, runtime, and eventual retirement. Containers share the host kernel, so a single compromised container can lead to host takeover or lateral movement across the cluster. Kubernetes orchestrates containers, adding complexity with its control plane, etcd, and network policies. The SC-200 exam focuses on Microsoft's security solutions for Azure Kubernetes Service (AKS), including Microsoft Defender for Containers, Azure Policy for Kubernetes, and integration with Microsoft Sentinel.

Microsoft Defender for Containers is a cloud-native solution that provides threat detection for AKS clusters and container registries. It consists of two main components:

When you enable the Defender for Containers plan on a subscription, Defender for Cloud automatically deploys two agents to each AKS node:

To enable Defender for Containers on an existing AKS cluster:

az aks enable-addons --addons azure-policy --name <cluster-name> --resource-group <rg>
az aks update --name <cluster-name> --resource-group <rg> --enable-defender

For new clusters, you can enable both during creation:

az aks create --name <cluster-name> --resource-group <rg> --enable-addons azure-policy --enable-defender

After enabling, verify the DaemonSet is running:

kubectl get daemonset -n kube-system | grep defender

The Defender profile uses eBPF to hook system calls such as execve, open, connect, and bind. When a suspicious event occurs (e.g., a container executes curl to an external IP), the agent:

Azure Policy for Kubernetes uses Gatekeeper (an admission controller webhook) to enforce policies on resources at creation time. For example, a policy might require all containers to run as non-root. When a user attempts to create a Pod that violates the policy, the API server rejects the request with a message explaining the violation. This prevents insecure configurations from ever being deployed.

Defender for Containers also integrates with Azure Container Registry (ACR) to scan images for vulnerabilities. The scan occurs on every push to the registry and is triggered again when new vulnerabilities are disclosed (e.g., a new CVE). The scan results are reported as recommendations in Defender for Cloud, such as "Container images should be scanned for vulnerabilities" (recommendation ID: 6a3e6e5b-...).

Microsoft Sentinel supports Kubernetes data connectors for:

Sentinel provides built-in analytics rules for Kubernetes threats, such as "Kubernetes API server activity from unexpected IP" or "Cluster role binding modified to grant admin access". You can also create custom hunting queries using KQL (Kusto Query Language).

Example KQL query to find privileged containers:

KubeEvents
| where EventType == "PodCreated"
| extend PodName = tostring(parse_json(EventObject).metadata.name)
| where EventObject has "privileged: true"

| Detection Type | Data Source | Example Alert | |----------------|-------------|---------------| | Image vulnerability | ACR scan | "Container image has critical vulnerabilities" | | Runtime threat | eBPF events (host/container) | "Crypto miner detected in container" | | Kubernetes audit | API server logs | "Suspicious kubectl exec to Pod" | | Host-level threat | Defender for Cloud (Azure VM) | "SSH brute force from compromised node" |

A fintech company runs a payment processing application on AKS. They must comply with PCI DSS, which requires vulnerability scanning, access control, and audit logging. They enable Defender for Containers and assign Azure Policy to enforce that all containers run as non-root and have read-only root filesystems. They configure a custom Azure Policy to reject images from untrusted registries. Vulnerability scans on ACR catch a critical CVE in a base image; the alert triggers an automatic pipeline that rebuilds the image and redeploys all affected Pods. In production, they have 50 nodes and 500 Pods; the Defender profile consumes less than 5% CPU overhead per node. They also stream audit logs to Sentinel and create an analytics rule that alerts when a cluster role binding grants cluster-admin to a service account. One incident: an attacker compromised a developer's credentials and created a privileged Pod to mine cryptocurrency. Defender detected the cryptomining behavior within 2 minutes and sent a high-severity alert. The security team used Sentinel to trace the attacker's actions and revoked the compromised credentials.

A large e-commerce company runs 20 AKS clusters across multiple regions. They use Azure Arc to unify security management. They enable Defender for Containers on all clusters via Azure Policy at the management group level. They use Azure Policy to enforce network policies (Calico) that restrict egress traffic to only approved external IPs. They also deploy a custom Falco rule to detect when a container spawns a shell (e.g., sh or bash). They integrate Sentinel with all clusters and use a single Log Analytics workspace. Performance: each cluster has 100-200 nodes; the Defender profile uses 50MB memory per node. They faced a misconfiguration where the Defender profile was missing from one cluster because the AKS update command failed silently. They caught it by running a custom Azure Monitor alert that checks for the DaemonSet's desired vs. current count. The fix: re-run az aks update --enable-defender.

A healthcare provider stores patient data in an AKS cluster. They must comply with HIPAA, which requires encryption at rest and in transit. They enable Defender for Containers and also use Azure Policy to enforce that secrets are mounted from Azure Key Vault via CSI driver, not as environment variables. They configure audit logs to be retained for 1 year (365 days) by extending Log Analytics retention to 730 days. They use Sentinel to create a custom hunting query that detects any access to a Pod containing patient data (labeled with data-classification=phi). They also enable network policy to deny all ingress except from a specific application gateway. One incident: a developer accidentally exposed a Kubernetes dashboard via a LoadBalancer service. Defender alerted "Kubernetes dashboard exposed to internet" within minutes. The team deleted the service and applied a network policy to block public access.