0Pricing
Cyber Security Academy · Leçon

Modèle de menace de Kubernetes

Les points d’attaque des grappes.

Modèle de menace de Kubernetes est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.

Pourquoi Kubernetes est une cible

Kubernetes orchestre des conteneurs sur de nombreux nœuds. Il centralise les secrets, le réseau et les ressources de calcul ; compromettre le cluster peut donc revenir à compromettre chaque charge de travail qu’il exécute.

  • Un seul serveur d’API contrôle l’ensemble du cluster.
  • Les nœuds exécutent côte à côte les charges de travail de nombreux locataires.
  • La mauvaise configuration est bien plus courante que les vulnérabilités CVE du cœur de Kubernetes.

Récapitulatif de l’architecture du cluster

Pour modéliser les menaces, connaissez les composants.

  • Plan de contrôle : serveur d’API, etcd, ordonnanceur, gestionnaire de contrôleurs.
  • Nœuds : kubelet, environnement d’exécution des conteneurs, kube-proxy, pods.
  • etcd stocke tout l’état du cluster et les secrets.

Le serveur d’API est le point d’entrée unique ; etcd est le joyau des données.

Cartographie de la surface d’attaque

Les attaques ciblent des couches distinctes.

  • Externe : serveur d’API exposé, tableaux de bord, points d’entrée.
  • Charge de travail : application compromise à l’intérieur d’un pod.
  • Identité : jetons de comptes de service et RBAC.
  • Nœud : API du kubelet, évasion du conteneur vers l’hôte.
  • Chaîne d’approvisionnement : images et dépendances malveillantes.

Plan de contrôle exposé

Un serveur d’API ou un kubelet accessible depuis Internet avec une authentification faible constitue un accès direct à la prise de contrôle du cluster.

  • Accès anonyme activé sur le serveur d’API.
  • API de lecture/écriture du kubelet (port 10250) exposée.
  • Tableau de bord Kubernetes ouvert avec une liaison d’administrateur.
# Probe an exposed kubelet for running pods
curl -sk https://NODE_IP:10250/pods

# Test anonymous API access
kubectl --insecure-skip-tls-verify --server https://API:6443 get pods

Point d’appui dans un pod

Le point de départ le plus courant est une RCE dans une application exécutée dans un pod. Depuis l’intérieur d’un pod, les attaquants trouvent :

  • Un jeton de compte de service monté à l’emplacement /var/run/secrets/....
  • Des services internes accessibles (aucune politique réseau).
  • Le serveur d’API, souvent résoluble sous le nom kubernetes.default.
# From inside a pod: read the mounted SA token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Use it against the API
curl -sk -H "Authorization: Bearer $(cat .../token)" https://kubernetes.default/api/v1/namespaces/default/pods

Évasion de conteneur

Sortir d’un conteneur pour atteindre le nœud donne accès à toutes les charges de travail de cet hôte.

  • Les conteneurs privilégiés peuvent accéder aux périphériques de l’hôte et s’évader.
  • Les montages hostPID/hostNetwork/hostPath élargissent l’ampleur des dégâts.
  • Un socket Docker monté permet de démarrer un conteneur privilégié.
  • Des capacités dangereuses (SYS_ADMIN) permettent l’évasion.
# A privileged pod can mount the host filesystem and chroot to it
mount /dev/sda1 /mnt && chroot /mnt sh

etcd : le coffre à secrets

etcd contient tout l’état du cluster, y compris les secrets, qui ne sont encodés en base64 par défaut. Un accès direct à etcd (souvent sans authentification dans les clusters mal configurés) divulgue tous les secrets.

# Read all secrets from an exposed etcd
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-only

Déplacement latéral dans les clusters

Une fois à l’intérieur, les attaquants se déplacent en exploitant l’identité et le réseau du cluster.

  • Un compte de service doté d’autorisations trop larges vous permet de créer des pods privilégiés.
  • Les réseaux de pods plats (sans NetworkPolicy) permettent d’atteindre n’importe quel service.
  • Planifier un pod sur un nœud cible permet de compromettre ce nœud.

Métadonnées du cloud depuis les pods

Dans les clusters gérés (EKS/GKE/AKS), les pods peuvent atteindre le service de métadonnées cloud du nœud et voler les identifiants IAM/de rôle du nœud, faisant le lien entre la compromission du cluster et le compte cloud.

Les défenses comprennent IMDSv2, le blocage des métadonnées au niveau du réseau et l’utilisation d’une identité de charge de travail plutôt que de rôles de nœud.

Cartographier avec des outils

Les outils automatisent l’évaluation des menaces du cluster.

  • kube-hunter recherche les composants exposés.
  • kube-bench vérifie la conformité au référentiel CIS.
  • Peirates / kubeletctl explorent les chemins d’attaque au sein du cluster.
# Assess attack surface
kube-hunter --remote API_IP

# CIS benchmark check on a node
kube-bench run --targets node

Priorités défensives

Le modèle de menace indique des priorités défensives claires : verrouiller le serveur d’API, restreindre RBAC, isoler les pods, renforcer les nœuds et sécuriser la chaîne d’approvisionnement. Les prochaines leçons approfondissent chacun de ces points.

Lors d’une évaluation, n’attaquez que les clusters pour lesquels vous disposez d’une autorisation et évitez de déstabiliser les charges de travail de production.

Vérification rapide

Vérifiez vos connaissances fondamentales de la modélisation des menaces Kubernetes.

Récapitulatif

Vous avez cartographié les points d’attaque des clusters Kubernetes.

  • Le serveur d’API et etcd sont les cibles centrales et les plus précieuses.
  • Les points d’appui dans les pods exploitent les jetons SA montés et les réseaux plats.
  • Les pods privilégiés utilisant hostPath permettent de s’évader du conteneur vers le nœud.
  • Les clusters gérés présentent un risque de pivot vers le cloud via les métadonnées.

Ensuite : RBAC et comptes de service.

Questions Fréquemment Posées

La leçon « Modèle de menace de Kubernetes » est-elle gratuite ?

Oui — le texte complet de « Modèle de menace de Kubernetes » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Modèle de menace de Kubernetes » ?

Les points d’attaque des grappes. Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?

Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Modèle de menace de Kubernetes » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?

Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Modèle de menace de Kubernetes
  2. RBAC et comptes de service
  3. Sécurité des pods et politiques réseau
  4. Sécuriser la chaîne d’approvisionnement et les secrets
← Retour à Cyber Security Academy