1. Comment communiquent les conteneurs #
Le networking de base.
Modèle #
- Docker : réseaux bridge par hôte (isolation par réseau nommé), réseaux overlay entre hôtes Swarm.
- Kubernetes : chaque pod a une IP, tous les pods peuvent se joindre par défaut ; le CNI (Calico, Cilium, Flannel) implémente ce réseau.
- Les Services donnent une adresse stable ; l'Ingress ou la Gateway API exposent vers l'extérieur.
Erreur Courante : Par défaut, Kubernetes n'isole rien : un pod compromis peut joindre toutes les bases du cluster. La première mesure est une politique de refus par défaut.
2. Les mesures #
Couche par couche.
NetworkPolicies #
# Refus par défaut dans le namespace, puis ouverture explicite
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: shop }
spec: { podSelector: {}, policyTypes: [Ingress, Egress] }
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: api-to-db, namespace: shop }
spec:
podSelector: { matchLabels: { app: postgres } }
ingress:
- from: [ { podSelector: { matchLabels: { app: api } } } ]
ports: [ { port: 5432 } ]À savoir : Les NetworkPolicies ne s'appliquent que si le CNI les implémente (Calico, Cilium oui ; Flannel seul non). Pensez à autoriser le DNS (port 53 vers kube-dns) dans les règles de sortie.
Autres couches #
| Mesure | Outil | Protège contre |
|---|---|---|
| mTLS entre services | Istio, Linkerd, Cilium | Écoute et usurpation sur le réseau du cluster |
| Contrôle des sorties | Politiques egress, proxy sortant | Exfiltration de données, téléchargement d'outils |
| Entrée | Ingress avec TLS, WAF, limitation de débit | Attaques applicatives |
| Observabilité des flux | Hubble (Cilium), Network Performance Monitoring | Flux inattendus non détectés |
