Container Escape on Azure

Container escape in Azure environments typically exploits the boundary between containerized workloads and the underlying host infrastructure. In Azure Kubernetes Service (AKS), this vulnerability allows attackers to break out of their container and gain access to the node's operating system, potentially escalating to cluster-wide control.

The most common Azure-specific container escape vectors involve leveraging privileged containers, hostPath mounts, and Azure Instance Metadata Service (IMDS) access. When containers run with elevated privileges or mount sensitive host directories, attackers can traverse from the container filesystem to the host filesystem, accessing root-level resources.

Consider this vulnerable Azure deployment configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vulnerable-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: vulnerable-app:latest
        securityContext:
          privileged: true  # Critical vulnerability
        volumeMounts:
        - name: host-vol
          mountPath: /host
      volumes:
      - name: host-vol
        hostPath:
          path: /  # Mounts entire host filesystem
          type: Directory

This configuration grants the container full host access. An attacker who compromises this container can execute commands like chroot /host to pivot to the host environment, then access /var/run/docker.sock to control other containers or execute arbitrary commands on the node.

Azure IMDS exploitation represents another critical attack path. Containers can access http://169.254.169.254/metadata/instance to retrieve instance metadata including managed identity tokens, SSH keys, and network configuration. If a container escapes to the host, it gains the same IMDS access as the node, potentially exposing credentials for Azure services.

Azure Container Instances (ACI) present unique risks when configured with incorrect isolation settings. The default isolation model uses hyper-isolated containers, but certain configurations may revert to less secure isolation levels, creating escape opportunities.

Real-world exploitation often follows this pattern: an attacker identifies a vulnerable container through network scanning, exploits a vulnerability in the application code (such as a command injection flaw), then uses the privileged access to mount /proc or /sys filesystems and manipulate kernel structures to break containment.

Detecting container escape vulnerabilities in Azure requires both runtime monitoring and static analysis of deployment configurations. Azure Security Center provides baseline protection by flagging privileged containers and excessive hostPath mounts, but comprehensive detection needs deeper analysis.

middleBrick's Azure-specific scanning examines deployment manifests, Helm charts, and live endpoints for escape vectors. The scanner analyzes YAML configurations for securityContext settings, volume mounts, and network policies that could enable container breakout.

Key detection patterns include:

# Vulnerable patterns detected by middleBrick
securityContext:
  privileged: true
  runAsUser: 0
  allowPrivilegeEscalation: true
volumeMounts:
- mountPath: /host
  readOnly: false
- mountPath: /var/run/docker.sock
  readOnly: false
capabilities:
  add: ["SYS_ADMIN", "NET_ADMIN"]

middleBrick also tests runtime behavior by attempting controlled access to sensitive paths and services. For Azure-specific detection, the scanner checks for:

• Access to Azure Instance Metadata Service from container contexts
• Capability to mount /proc and /sys filesystems
• Network namespace manipulation attempts
• Access to /var/run/docker.sock or container runtime sockets

The scanner generates a security risk score with specific findings for each detected vulnerability, providing severity levels and remediation guidance. For Azure environments, findings map to compliance requirements including Azure Security Benchmark and CIS Kubernetes benchmarks.

Azure Monitor integration allows continuous detection of anomalous container behavior. Security teams can configure alerts for suspicious patterns like unexpected host filesystem access, privilege escalation attempts, or IMDS metadata requests from containers.

Remediating container escape vulnerabilities in Azure requires a defense-in-depth approach combining configuration hardening, runtime protection, and architectural controls. The primary mitigation is eliminating unnecessary privileges and restricting container capabilities.

Secure Azure deployment configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: secure-app:latest
        securityContext:
          privileged: false
          allowPrivilegeEscalation: false
          runAsNonRoot: true
          runAsUser: 1000
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: app-data
          mountPath: /data
          readOnly: false
      volumes:
      - name: app-data
        emptyDir: {}
      - name: tmp
        emptyDir:
          medium: Memory

This configuration eliminates privileged access, runs as a non-root user, drops all Linux capabilities, and uses only necessary volumes. Azure-specific hardening includes configuring network policies to restrict container-to-host communication and implementing Azure Policy to enforce security standards across AKS clusters.

Azure Defender for Kubernetes provides runtime protection by monitoring container behavior and alerting on suspicious activities. Enable container runtime protection and configure it to detect:

• Privilege escalation attempts
• Unexpected host filesystem access
• IMDS metadata service abuse
• Network namespace manipulation

For Azure Container Instances, use the default hyper-isolated containers and avoid custom isolation configurations unless absolutely necessary. Implement Azure Policy to prevent deployment of containers with privileged flags or dangerous volume mounts.

Network segmentation is critical: configure Azure Network Security Groups to restrict container egress traffic, preventing containers from accessing external services that could be used for command-and-control or data exfiltration.

Regular security scanning with middleBrick should be integrated into CI/CD pipelines using the GitHub Action. This ensures that deployment manifests are scanned before production deployment, catching container escape vulnerabilities early in the development lifecycle.

middleBrick's scanning results include specific remediation steps for Azure environments, such as replacing privileged containers with least-privilege alternatives, removing dangerous volume mounts, and implementing proper network isolation.