Network Policies et chiffrement pod-to-pod Kubernetes

Les network policies Kubernetes contrôlent le trafic réseau entre pods, namespaces et endpoints externes. Sans ces règles, chaque pod communique librement avec tous les autres, créant une surface d'attaque massive. Le chiffrement pod-to-pod ajoute une couche de confidentialité essentielle pour les données sensibles en transit.

TL;DR : Déployez des NetworkPolicies par défaut deny-all, puis autorisez explicitement les flux nécessaires. Activez le chiffrement mTLS via un service mesh pour protéger les communications inter-pods.

Pour maîtriser ces compétences critiques, suivez la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes.

Qu'est-ce qu'une Network Policy Kubernetes ?

Une Network Policy est une ressource Kubernetes native définissant les règles de trafic réseau au niveau 3/4 (IP/port). Elle spécifie quels pods peuvent communiquer entre eux via des sélecteurs de labels.

Par défaut, Kubernetes autorise tout le trafic entre pods. Ce comportement permissif facilite le développement mais expose la production.

Selon le CNCF Annual Survey 2025, 82% des organisations exécutent Kubernetes en production. Chaque cluster non segmenté représente un risque de mouvement latéral pour les attaquants.

À retenir : Sans Network Policy, un pod compromis accède à tous les autres pods du cluster. La segmentation limite la propagation des attaques.

Comment implémenter les network policies Kubernetes de base ?

Commencez par une politique deny-all qui bloque tout trafic par défaut, puis ajoutez des règles d'autorisation explicites.

Politique deny-all par namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Cette policy s'applique à tous les pods du namespace production et bloque tout trafic entrant et sortant.

Autoriser le trafic applicatif spécifique

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Pour une formation Kubernetes complète, explorez nos parcours incluant la sécurité réseau.

À retenir : Appliquez le principe deny-by-default. Chaque flux autorisé doit correspondre à un besoin applicatif documenté.

Quels CNI supportent les network policies Kubernetes ?

Les Network Policies nécessitent un CNI (Container Network Interface) compatible. Tous les CNI ne supportent pas cette fonctionnalité.

Comparatif des CNI

Vérifiez votre CNI actuel :

# Identifier le CNI déployé
kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=cilium

Cilium et Calico offrent des fonctionnalités avancées comme les policies L7 (HTTP, gRPC) et l'observabilité réseau intégrée.

Pour approfondir l'administration cluster Kubernetes, consultez notre guide dédié.

Comment configurer les network policies Kubernetes avancées ?

Au-delà des règles basiques, les Network Policies supportent des sélecteurs complexes pour des architectures microservices.

Autoriser le trafic depuis un namespace spécifique

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
    ports:
    - protocol: TCP
      port: 9090

Autoriser le trafic vers des IPs externes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-external-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 203.0.113.0/24
    ports:
    - protocol: TCP
      port: 443

Selon Orca Security 2025, 70% des organisations utilisent Kubernetes en cloud avec Helm. Les Network Policies doivent s'intégrer aux charts de déploiement.

À retenir : Combinez podSelector, namespaceSelector et ipBlock pour des règles granulaires adaptées à votre architecture.

Explorez les bonnes pratiques Kubernetes production pour compléter votre stratégie réseau.

Comment activer le chiffrement pod-to-pod Kubernetes ?

Le chiffrement pod kubernetes protège les données en transit contre l'interception. Trois approches principales existent.

Option 1 : WireGuard avec Calico

# calico-installation.yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    bgp: Disabled
    ipPools:
    - cidr: 192.168.0.0/16
      encapsulation: WireguardCrossSubnet

Vérifiez l'activation :

# Statut WireGuard sur les nodes
calicoctl node status
kubectl get nodes -o custom-columns='NAME:.metadata.name,WIREGUARD:.metadata.annotations.projectcalico\.org/WireguardPublicKey'

Option 2 : mTLS avec Istio

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

Le service mesh injecte automatiquement les sidecars Envoy pour le chiffrement mTLS transparent.

Option 3 : IPsec avec Cilium

# Installation Cilium avec chiffrement
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set encryption.enabled=true \
  --set encryption.type=ipsec

Pour maîtriser la sécurité Kubernetes, une formation structurée accélère l'acquisition.

Quelles sont les policies L7 pour le chiffrement et le filtrage HTTP ?

Les policies niveau 7 filtrent le trafic HTTP/gRPC, offrant une granularité supérieure aux Network Policies natives.

Cilium Network Policy L7

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/products"
        - method: POST
          path: "/api/v1/orders"

Cette policy autorise uniquement les requêtes GET sur /api/v1/products et POST sur /api/v1/orders.

À retenir : Les policies L7 exigent un CNI compatible (Cilium, Istio). Elles complètent les Network Policies natives sans les remplacer.

Consultez le guide sur le monitoring Kubernetes avec Prometheus et Grafana pour observer le trafic réseau.

Comment tester et valider les network policies Kubernetes ?

Testez systématiquement vos policies avant la mise en production. Un trafic bloqué par erreur provoque des incidents applicatifs.

Test avec un pod debug

# Créer un pod de test
kubectl run debug --rm -it --image=nicolaka/netshoot -- bash

# Depuis le pod, tester la connectivité
curl -v http://backend.production:8080/health
nc -zv backend.production 8080

Visualisation avec Cilium Hubble

# Observer les flux en temps réel
hubble observe --namespace production --verdict DROPPED
hubble observe --namespace production --verdict FORWARDED

Audit des policies appliquées

# Lister les NetworkPolicies par namespace
kubectl get networkpolicies -A

# Détail d'une policy
kubectl describe networkpolicy allow-frontend-to-backend -n production

Selon Spectro Cloud State of Kubernetes 2025, les équipes gèrent en moyenne 20+ clusters. L'automatisation des tests réseau devient critique à cette échelle.

Pour le dépannage réseau Kubernetes, maîtrisez les outils d'observabilité.

Checklist de sécurité réseau Kubernetes

Validez chaque point pour une segmentation robuste :

• [ ] Politique deny-all par défaut sur chaque namespace
• [ ] Règles ingress explicites pour chaque service
• [ ] Règles egress limitant l'accès aux APIs externes
• [ ] CNI compatible Network Policies (Calico, Cilium)
• [ ] Chiffrement pod-to-pod activé (WireGuard, mTLS)
• [ ] Tests de connectivité automatisés
• [ ] Observabilité des flux réseaux (Hubble, Goldilocks)
• [ ] Documentation des flux autorisés

À retenir : La sécurité réseau Kubernetes combine segmentation (Network Policies), chiffrement (mTLS/WireGuard) et observabilité (Hubble/Prometheus).

Passez à l'action : formez-vous à la sécurité réseau Kubernetes

La formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes couvre les Network Policies, le chiffrement pod-to-pod et la préparation à la certification CKS. En 4 jours, maîtrisez la segmentation réseau et la défense en profondeur.

Prochaines étapes :

• Explorez les certifications Kubernetes CKA CKAD CKS
• Découvrez Kubernetes pour les développeurs LFD459
• Consultez le calendrier des formations

Contactez nos conseillers pour construire votre parcours sécurité Kubernetes.