Kubernetes Privilege Escalation: Container Escape == Cluster Admin?

## Overview

In the presentation *"Kubernetes Privilege Escalation: Container Escape == Cluster Admin?"*, cloud security researchers from Palo Alto Networks investigate whether an attacker who successfully escapes a single container can escalate privileges to achieve full cluster administrative access. While containers provide packaging and deployment benefits, the shared Linux kernel creates a weak security boundary where local kernel vulnerabilities or common misconfigurations (such as privileged containers with host access) allow attackers to break out and compromise the underlying host node.

The speakers explore the blast radius of such compromises, examining attacker motivations—from cryptomining and accessing compute resources to moving laterally, compromising databases, stealing secrets, and pivoting to adjacent cloud environments.

## Core Problem and Attack Model

The researchers define the central research question: does compromising a single node via a container escape grant an ambitious attacker cluster-wide dominance? To analyze escalation paths, the speakers distinguish between two authorization levels: - **Admin**: The capability to perform any operation across all namespaces. - **Admin-Equivalent**: Possessing sufficient permissions to achieve full administrative access in one or two trivial escalation steps.

The presentation notes that container escapes are an ongoing reality rather than theoretical concerns, highlighting that 2022 alone saw at least a dozen container escape vulnerabilities introduced, alongside active threat actors leveraging container breakouts for cryptomining and lateral movement.

## Kubernetes Architecture and Escalation Primitives

To establish how an attacker navigates from a compromised node to higher privileges, the talk reviews fundamental Kubernetes components and authentication mechanisms: - **Control Plane & Gateway**: The Kubernetes API server acts as the cluster gateway and brain, receiving commands (e.g., via `kubectl`) and scheduling pods onto underlying nodes. - **Authentication Mechanisms**: - **Certificates**: Primarily used to authenticate users and worker nodes directly to the API server. - **Service Account Tokens**: Used by pods and container workloads to authenticate their API requests. - **Authorization Model**: Kubernetes governs access via Role-Based Access Control (RBAC), where permissions are defined by verbs applied to specific resources (such as `create pod`, `update node`, or `delete services`). These permissions are grouped into roles and assigned to identities using role bindings.

Once an attacker breaks out of a container and lands on a node, they gain access to node-level credentials (including node certificates and service account tokens residing on that host), which serve as the foundation for testing whether standard or platform-specific configurations permit escalation to cluster admin.