Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Kubernetes Attack Surface

cloud

Définition

La Kubernetes Attack Surface est l'ensemble des vecteurs d'attaque potentiels dans un cluster Kubernetes. Elle comprend le plan de contrôle (kube-apiserver, etcd, kubelet), le réseau (NodePorts, LoadBalancers, NetworkPolicies permissives), les workloads (images vulnérables, conteneurs privilegiés, hostPath mounts), et la supply chain (images publiques non vérifiées, Helm charts de sources non fiables). Le plan de contrôle est la cible la plus critique : le kube-apiserver expose l'API Kubernetes sur le port 6443. Une authentification anonyme activée ou des autorisations RBAC trop permissives permettent à n'importe qui d'atteindre le cluster. Le kubelet écoute sur le port 10250 et peut permettre l'exécution de commandes dans les pods si mal configuré. Au niveau réseau, chaque service NodePort crée un point d'entrée sur tous les nœuds du cluster. Les LoadBalancers exposent des services directement sur Internet. L'absence de NetworkPolicies par défaut (default deny) permet à n'importe quel pod de communiquer avec n'importe quel autre pod, facilitant le mouvement latéral après compromission d'un pod. Les workloads non durcis constituent la majorité de la surface d'attaque : conteneurs s'exécutant en root, images avec des CVEs critiques, volumes hostPath montant le filesystem hôte dans le conteneur, et ServiceAccounts avec des droits RBAC excessifs permettant de contrôler d'autres pods ou de lire des Secrets. La réduction de la surface d'attaque Kubernetes suit une approche en couches : réduire les composants exposés réseau, renforcer l'authentification RBAC, appliquer le moindre privilège aux workloads, sécuriser les images (scan, signing), et surveiller en temps réel avec Falco ou Sysdig pour détecter les comportements anormaux indiquant une exploitation.

kube-hunter : évaluation de la surface d'attaque

kube-hunter (Aqua Security) évalue la surface d'attaque Kubernetes depuis deux perspectives : mode remote (depuis Internet, simule un attaquant externe) et mode in-cluster (depuis un pod, simule un pod compromis). En mode remote, kube-hunter tente de se connecter au kube-apiserver, au kubelet, et au dashboard Kubernetes pour identifier les accès non authentifiés. En mode in-cluster, il tente d'accéder à l'API Kubernetes, de lire les tokens des ServiceAccounts, et d'explorer les permissions RBAC disponibles.

Réduction des points d'entrée réseau

Auditez les services NodePort et LoadBalancer : kubectl get svc --all-namespaces | grep -E 'NodePort|LoadBalancer'. Limitez les LoadBalancers aux services réellement exposés sur Internet, avec des Security Groups restrictifs. Remplacez les NodePorts par des Ingress Controllers (NGINX, Traefik) avec WAF intégré. Appliquez des NetworkPolicies default-deny dans chaque namespace et définissez explicitement les flux autorisés.

Defense in Depth Kubernetes

Couche 1 Réseau : NetworkPolicies restrictives, Ingress avec WAF. Couche 2 Workloads : seccompProfile RuntimeDefault, capDrop ALL, readOnlyRootFilesystem, runAsNonRoot. Couche 3 RBAC : ServiceAccounts dédiés à permissions minimales, pas de ClusterAdmin pour les applications. Couche 4 Images : signed images depuis registre de confiance, scan CVE en CI/CD. Couche 5 Runtime : Falco pour la détection comportementale et les Kubernetes Audit Logs pour la forensique.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis