la permission Kubernetes nodes/proxy GET, ressemblant d'apparence à une permission "read-only" peut être détournée pour exécuter des commandes à distance dans n’importe quel Pod accessible sur les nœuds du cluster.
Prérequis
Un service account avec la permission RBAC :
nodes/proxy avec le verbe GET
Une connectivité réseau vers le Kubelet (port 10250) des nœuds
Accès à un Pod ou un environnement où ce token est utilisable
Des outils capables de parler WebSocket (ex : websocat)
Détails techniques
1. Mauvaise interprétation RBAC
Kubernetes mappe les permissions RBAC selon la méthode HTTP.
GET autorise nodes/proxy GET, considéré comme lecture.
2. Problème avec WebSockets
L’endpoint /exec du Kubelet utilise WebSockets.
Une connexion WebSocket commence par un HTTP GET (upgrade handshake).
Résultat :
Le Kubelet valide uniquement le GET initial
Il ne revalide pas l’opération réelle (exec) après upgrade
3. Contournement
L’attaquant initie une connexion WebSocket vers /exec
L’autorisation est validée sur le GET du handshake
Puis la connexion est utilisée pour exécuter des commandes dans le conteneur
4. Impact
Exécution de commandes dans n’importe quel Pod accessible
Accès à des Pods système
Possibilité d’extraction de secrets et pivot dans le cluster
Potentiellement prise de contrôle complète du cluster