~10 minutes
Cet article fait partie de la série OWASP Top 10 Kubernetes 2026. Retrouvez le tableau de bord complet des dix risques et la matrice STRIDE sur la page d’entrée de la série.
K03 couvre un défaut presque banal : dans beaucoup de clusters, le réseau interne est plat. Un pod compromis peut scanner les services, interroger le DNS interne, parler à des workloads qui n’ont aucun lien métier avec lui, puis sortir vers Internet sans contrôle sérieux.
Kubernetes ne segmente pas le trafic applicatif par défaut. Les NetworkPolicy existent, mais elles ne s’appliquent que si le CNI les supporte et si quelqu’un les écrit. Entre ces deux conditions, il y a assez d’espace pour un mouvement latéral très confortable.
Vecteurs d’attaque
Le namespace tout a plat
Le namespace Kubernetes aide à organiser, à poser du RBAC et à appliquer des quotas. Il n’isole pas le réseau à lui seul. Sans policy, frontend peut parler à database, batch peut parler à admin, et un pod compromis peut cartographier tranquillement les services.
Passez ce test rapide avant de parler d’architecture a un SRE/OPS :
kubectl run netshoot -n app --image=nicolaka/netshoot --rm -it -- sh
dig +short kubernetes.default.svc.cluster.local
nc -vz database.database.svc.cluster.local 5432
Si tout répond depuis n’importe où => Paf le chien…ou Badaboum le chat… Il va falloir discuter, on a pas inventer les VLAN réseaux pour rien, donc on va regarder ce Kube avec le même prisme
L’egress libre
Beaucoup d’équipes traitent l’ingress en priorité et oublient l’egress. Pourtant, après compromission, l’egress libre permet l’exfiltration, le téléchargement d’outils, le callback C2 et la résolution DNS vers des domaines externes.
La règle d’exploitation est simple : un workload qui n’a pas besoin de sortir vers Internet ne sort pas. Un workload qui doit sortir sort vers des destinations explicites, validées tracées et documentées
Le DNS interne trop bavard
CoreDNS donne une excellente carte du cluster à qui sait l’interroger. Ce n’est pas une vulnérabilité de CoreDNS. C’est un effet de bord normal d’un cluster sans cloisonnement réseau(coucou la séggrégation)
Les requêtes DNS importantes ou inhabituelles sont souvent un bon signal faible : un pod qui ne faisait que servir HTTP commence à résoudre des dizaines de services internes et des domaines externes inconnus.
Les services exposés sans justification
Un Service de type LoadBalancer dans un namespace applicatif ne devrait jamais être anodin. Même constat pour les NodePort et les ingress trop larges. Avec Gateway API, on peut clarifier les responsabilités, mais il faut quand même gouverner qui expose quoi, depuis quel namespace, et avec quels contrôles.
Mitigations prioritaires
Default-deny par namespace applicatif
La baseline K03 tient en deux policies : deny-all ingress et deny-all egress. Ensuite seulement, on ouvre les flux métier.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Un point de vigilance : déployer ce type de policy sans inventaire casse la production.
La séquence qui tient le mieux est progressive :
- activer des logs ,
- observer une semaine de trafic normal,
- lister les flux réellement utilisés,
- poser les policies en mode warning quand l’outil le permet,
- puis passer en enforcement namespace par namespace.
Les flux liés aux batchs, webhooks et jobs de maintenance doivent être testés à part. Ils ne se voient pas toujours pendant un test manuel de cinq minutes.
Ouvrir les flux métier, pas les habitudes
On part des dépendances applicatives, pas de la topologie rêvée. L’interface web appelle l’API. L’API ouvre une connexion vers PostgreSQL. Les pods résolvent leurs noms via CoreDNS. Les tâches planifiées parlent parfois à un service de reporting ou à une API externe. Tout ce qui ne rentre pas dans cet inventaire doit être refusé ou justifié.
Dans l’article sur Cilium eBPF CNI Kubernetes 🚧, le point important est l’usage des identités et de l’observabilité.
Maîtriser l’egress HTTPS
Autoriser 0.0.0.0/0 en egress revient à dire “on verra plus tard”. Pour les workloads qui consomment des API externes, on passe par des domaines approuvés, un proxy egress, ou des policies L7 quand le contexte le permet.
Le but n’est pas de produire une usine à gaz. Le but est de rendre l’exfiltration détectable (coucou les logs et le SIEM).
Tester les policies
Une NetworkPolicy non testée est un commentaire YAML. Il faut des tests de connectivité attendue et interdite :
- interface web vers API : autorisé
- interface web vers base de données : refusé
- API vers base de données : autorisé
- pod compromis vers Internet : refusé
- DNS vers CoreDNS : autorisé, mais surveillé
Et bien sur on trace les refus dans le SIEM !!! (Sinon panpan cucul ! )
DevSecOps : intégrer K03 dans la chaîne CI/CD
Pour creuser les bases, l’article Bonnes pratiques pour sécuriser Kubernetes 🚧 reprend les NetworkPolicies avec des exemples progressifs.
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ Le namespace n'isole pas le réseau : sans NetworkPolicy, les pods peuvent généralement se parler.
- ✓ Default-deny d'abord : ingress et egress fermés par défaut, puis ouverture des flux métier.
- ✓ L'egress est un contrôle de sécurité : il limite exfiltration, callback et téléchargement d'outils après compromission.
- ✓ Les policies doivent être testées : un test refusé est aussi important qu'un test autorisé.
- ✓ Hubble rend les flux lisibles : très utile pour comprendre ce que les NetworkPolicies cassent ou protègent.