Lesson 24 — Microsoft Defender for Containers
Container platforms move quickly. Images are built, stored, deployed and replaced continuously across development and production environments.
Microsoft Defender for Containers protects Kubernetes clusters, registries, images, nodes and runtime workloads across Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Google Kubernetes Engine and Azure Arc-enabled Kubernetes.
This lesson follows the complete container security lifecycle: posture management, image vulnerability assessment, software supply-chain risk, admission and deployment controls, runtime detection, investigation and containment.
What you will learn
This lesson follows container security from image creation through deployment and runtime investigation.
How Microsoft Defender for Containers works
↓
Registry image is assessed for vulnerabilities
↓
Kubernetes posture and deployment configuration are evaluated
↓
Workload is deployed to AKS, EKS, GKE or Arc-enabled Kubernetes
↓
Runtime activity and Kubernetes control-plane events are monitored
↓
Suspicious behaviour generates a Defender for Cloud alert
↓
Agent Foskett connects the image, pod, identity, process, node and cluster
↓
The compromised workload is isolated
↓
The image, credentials and deployment configuration are remediated
↓
A trusted workload is redeployed
Five container security domains
| Domain | Purpose | Example |
|---|---|---|
| Posture management | Identify risky Kubernetes and workload configuration. | Privileged pods or exposed services. |
| Vulnerability assessment | Find vulnerable packages in images. | Critical library vulnerability in a running image. |
| Software supply chain | Reduce deployment of vulnerable or untrusted images. | Image from an unapproved registry. |
| Runtime protection | Detect malicious activity in live workloads. | Reverse shell or credential theft. |
| Multicloud visibility | Centralise container security across environments. | AKS, EKS, GKE and Arc clusters in one view. |
Learning objectives
- Explain Defender for Containers.
- Identify supported Kubernetes environments.
- Understand container posture management.
- Review image vulnerability findings.
- Recognise software supply-chain risks.
- Investigate runtime alerts.
- Contain compromised workloads.
What is Defender for Containers?
Microsoft Defender for Containers is a cloud-native security plan in Defender for Cloud that protects containerised assets throughout their lifecycle.
Protected assets
- Kubernetes clusters
- Cluster nodes
- Pods and workloads
- Container registries
- Container images
- Running containers
- Kubernetes control-plane activity
Supported environments
- Azure Kubernetes Service
- Amazon Elastic Kubernetes Service
- Google Kubernetes Engine
- Azure Arc-enabled Kubernetes
Security posture management
Defender for Containers evaluates Kubernetes configuration, workload settings and deployment practices to identify weaknesses before they become incidents.
Kubernetes recommendations
Recommendations highlight risky cluster configurations, exposed services, overly privileged workloads, insecure pod settings and missing protection components.
Image vulnerability assessment
Container images in supported registries and supported runtime environments are assessed for known vulnerabilities and affected packages.
Registry coverage
Defender can assess images in supported Azure, AWS and Google Cloud container registries. Coverage depends on the connected environment and enabled components.
Running-image context
Vulnerability findings become more useful when Defender can show whether the affected image is currently deployed and running in a cluster.
Risk-based prioritisation
A critical vulnerability in an unused image is different from the same vulnerability in an internet-facing production workload. Runtime and exposure context helps prioritise remediation.
Software supply-chain security
Container security begins before deployment. Defender helps identify vulnerable images, associate findings with workloads and support controls that reduce deployment of untrusted content.
Image provenance
Teams should know where an image came from, how it was built, which dependencies it contains and whether the build process was trusted.
Admission controls
Admission controls can evaluate Kubernetes resources before deployment and help prevent workloads that violate policy from entering the cluster.
Deployment controls
Security policy can restrict privileged containers, host networking, unsafe mounts, unapproved registries and other risky deployment choices.
Runtime threat protection
Runtime monitoring detects suspicious behaviour after a workload starts, including malicious processes, credential access, lateral movement and unusual Kubernetes activity.
Runtime anti-malware
Defender for Containers can detect and block supported malicious activity at container runtime in supported Kubernetes environments.
Kubernetes audit activity
Control-plane activity helps reveal suspicious commands, new role bindings, secret access, unusual deployments and unauthorised administrative actions.
Suspicious process execution
Unexpected shells, package tools, download utilities, crypto-mining processes or reconnaissance commands inside a container can indicate compromise.
Container escape indicators
Attempts to access the host, abuse privileged execution or manipulate sensitive kernel interfaces may indicate an attempted container escape.
Credential access
Attackers may search environment variables, mounted secrets, service-account tokens and cloud credentials after entering a container.
Lateral movement
A compromised pod may attempt to reach other services, namespaces, nodes, registries or cloud resources using the workload's identity and network access.
Exposed Kubernetes dashboard
Administrative interfaces exposed without strong authentication or network restriction can provide direct control of workloads and cluster resources.
Privileged containers
Privileged containers have extensive host access and should be limited to exceptional, well-governed use cases.
HostPath mounts
Mounting host paths into containers can expose sensitive node files and increase the impact of a compromised workload.
Root execution
Running containers as root increases the potential impact of application compromise. Use non-root identities wherever supported.
Secrets management
Do not hard-code secrets in images, manifests or environment variables without appropriate protection. Use controlled secret-management services and workload identities.
Workload identity
Managed workload identities reduce the need for static cloud credentials and improve attribution and control.
Network segmentation
Kubernetes network policies and cloud network controls should restrict pod-to-pod, namespace and external communication to required paths.
Namespace separation
Namespaces provide organisational separation but are not a complete security boundary. Combine them with RBAC, network policy and workload controls.
Kubernetes RBAC
Cluster roles and bindings should follow least privilege. Broad cluster-admin access creates a direct path to total cluster control.
Node security
Nodes require patching, secure configuration, restricted administration and monitoring because every workload ultimately depends on the host.
Cluster upgrades
Use supported Kubernetes versions and apply platform upgrades promptly. Unsupported versions can lose security fixes and Defender coverage.
Defender components
Enabled components depend on the cloud and feature set. Deployment can include Defender sensors, Azure Policy extensions, registry access and cloud connectors.
Multicloud connectors
AWS and Google Cloud environments connect to Defender for Cloud through cloud connectors that provide inventory, permissions and security integration.
Azure Arc-enabled Kubernetes
Azure Arc extends Defender for Containers management to supported Kubernetes clusters outside Azure, including on-premises and edge environments.
Alert evidence
- Cluster and namespace
- Pod and container
- Image and registry
- Node
- Process and command line
- Kubernetes identity
- Source and destination
- MITRE ATT&CK context
Initial triage
Confirm whether the workload is expected, identify the owning team, review the image, determine the process activity and establish the affected cluster scope.
Image investigation
Review the digest, registry, build pipeline, package vulnerabilities, deployment history and every workload using the same image.
Pod investigation
Review the pod specification, service account, mounted secrets, volumes, environment variables, network activity and recent process execution.
Identity investigation
Determine which Kubernetes user, service account, workload identity or cloud identity created or modified the resource.
Cluster investigation
Review role bindings, daemon sets, deployments, admission events, secrets, node activity and other alerts across the cluster.
Containment
- Isolate or delete the affected pod.
- Scale the compromised workload to zero.
- Block the malicious image digest.
- Revoke exposed credentials.
- Restrict network paths.
- Remove malicious Kubernetes resources.
- Preserve evidence before rebuilding.
Rebuild rather than repair
Containers are designed to be replaceable. After preserving evidence, redeploy from a trusted image and corrected configuration instead of manually repairing a compromised container.
Validation
Confirm the malicious image can no longer deploy, credentials are rotated, the corrected workload is healthy and no related activity remains elsewhere in the cluster.
Agent Foskett investigation: “The container lasted seven minutes…”
↓
The deployment passed its basic health checks
↓
Seven minutes later, Defender for Containers raised a runtime alert
↓
A shell process started inside the pod
↓
The process downloaded a script from an unfamiliar domain
↓
The pod read its mounted service-account token
↓
It began enumerating services in other namespaces
↓
Agent Foskett traced the activity to a vulnerable package in the image
↓
The image had been built from an outdated base image
↓
The same digest was running in three clusters
↓
The workloads were isolated
↓
The service-account credential was revoked
↓
Network access between namespaces was restricted
↓
The build pipeline was updated
↓
A patched image was scanned and redeployed
↓
The container disappeared after seven minutes
↓
But the image, identity and attack path would have remained
Container investigation checklist
| Area | Question | Evidence |
|---|---|---|
| Image | Which digest and registry produced the workload? | Deployment, registry and vulnerability findings. |
| Workload | Which pod, namespace and controller were involved? | Kubernetes metadata and alert entities. |
| Process | What executed and what did it attempt? | Process tree, command line and runtime alert. |
| Identity | Which service account or cloud identity was available? | Pod specification, tokens and role bindings. |
| Network | What systems did the workload contact? | Connections, DNS activity and network policy. |
| Scope | Where else is the same image or configuration deployed? | Registry inventory and cluster workload mapping. |
| Containment | Can the workload be rebuilt safely from a trusted source? | Updated image, policy and redeployment validation. |
Key takeaways
- Defender for Containers protects clusters, nodes, registries, images and runtime workloads.
- It supports AKS, EKS, GKE and Azure Arc-enabled Kubernetes.
- Container posture management identifies unsafe cluster and workload configuration.
- Image vulnerability assessment links package weaknesses to registries and running workloads.
- Software supply-chain security begins before deployment.
- Runtime monitoring detects suspicious processes, credential access and lateral movement.
- Kubernetes audit activity provides essential control-plane evidence.
- Identity, network policy and admission controls reduce attack paths.
- Compromised containers should normally be replaced from a trusted image.
- Investigators must connect temporary runtime evidence to the persistent image, identity and deployment configuration.
What Agent Foskett checked
- Cluster
- Namespace
- Pod
- Container image
- Image digest
- Registry
- Vulnerabilities
- Process tree
- Service account
- Role bindings
- Network activity
- Other deployments
Best practices
- Enable protection across every environment.
- Use supported Kubernetes versions.
- Scan images before deployment.
- Use trusted registries.
- Block privileged workloads.
- Run as non-root.
- Apply least-privilege RBAC.
- Use workload identity.
- Enforce network policy.
- Rebuild from trusted images.
Related Agent Foskett resources
Continue learning
What is Microsoft Defender for Containers?
Microsoft Defender for Containers is a Microsoft Defender for Cloud plan that protects Kubernetes clusters, registries, images, nodes and runtime workloads across Azure, AWS, Google Cloud and Azure Arc-enabled environments.
Microsoft Defender for Containers Lesson
This Agent Foskett lesson explains Kubernetes posture management, image vulnerability assessment, container software supply-chain security, runtime threat detection, multicloud deployment, investigation and containment.
