Par défaut, tous les pods d’un cluster Kubernetes peuvent se parler. C’est pratique au démarrage, catastrophique en production. Les Network Policies permettent d’implémenter le principe du moindre privilège réseau.
Le problème par défaut
Sans Network Policies, si un pod est compromis, l’attaquant peut atteindre n’importe quel autre pod du cluster — la base de données, le service de paiement, les secrets.
Politique deny-all : le point de départ
# Bloquer tout le trafic entrant dans un namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {} # s'applique à tous les pods
policyTypes: [Ingress]
Après cette policy, plus aucun pod du namespace production ne reçoit de trafic — vous ouvrez uniquement ce qui est nécessaire.
Autoriser uniquement le trafic légitime
# Autoriser l'API à parler à la base de données
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-to-db
namespace: production
spec:
podSelector:
matchLabels:
app: database
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
app: api # uniquement les pods api
ports:
- protocol: TCP
port: 5432
La base de données n’accepte que les connexions des pods api sur le port 5432.
Isoler des namespaces entre eux
# Interdire toute communication entre namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-namespace
namespace: production
spec:
podSelector: {}
policyTypes: [Ingress]
ingress:
- from:
- podSelector: {} # pods du même namespace uniquement
Vérifier les policies avec kubectl
# Lister les policies actives
kubectl get networkpolicies -n production
# Voir les règles détaillées
kubectl describe networkpolicy allow-api-to-db -n production
Notre formation Kubernetes couvre les Network Policies avec des ateliers sur des clusters réels.