Kubernetes Attack Surface
cloudDé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
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h