Surveillance et alertes des politiques réseau Kubernetes : guide pratique de mise en œuvre

Introduction

Les politiques réseau Kubernetes (Network Policies) sont essentielles pour contrôler le trafic de pod à pod et appliquer une mise en réseau zero-trust au sein d'un cluster. Cependant, définir des politiques n'est que la moitié du chemin. Sans surveillance et alertes efficaces, vous ne pouvez pas savoir si les politiques sont réellement appliquées, mal configurées ou si elles bloquent silencieusement un trafic légitime. Ce guide fournit une approche pratique, étape par étape, pour surveiller les politiques réseau Kubernetes à l'aide d'outils natifs, de Prometheus et de systèmes d'alerte. Vous apprendrez à collecter des métriques, à construire des tableaux de bord, à configurer des alertes et à répondre aux incidents avec des exemples concrets et des commandes.

Nous nous concentrerons sur des scénarios courants tels que la détection de trafic refusé, l'audit des modifications de politiques et le dépannage des problèmes de connectivité causés par des règles trop restrictives. Cet article s'adresse aux ingénieurs de plateforme, aux SRE (Site Reliability Engineers) et aux équipes DevOps qui exécutent Kubernetes en production.

Avant d'apporter des modifications, établissez toujours l'observabilité. L'objectif est de rendre visible le comportement des politiques réseau, de permettre un diagnostic rapide et de garantir que tout changement de configuration est sûr et réversible.

Inventaire des versions et de l'environnement

Avant de mettre en œuvre la surveillance, documentez votre environnement. Cet inventaire vous aidera à choisir les bons outils et à comprendre la compatibilité.

Détails du cluster et du CNI

L'application des politiques réseau dépend du plugin CNI (Container Network Interface). Les CNI courants qui prennent en charge les politiques réseau incluent Calico, Cilium, Weave Net et Antrea. Vérifiez votre CNI et sa version :

kubectl get nodes -o wide
# Vérifier les pods CNI
kubectl get pods -n kube-system | grep -E 'calico|cilium|weave|antrea'

Exemple de sortie (Calico) :

calico-node-abcde                    1/1     Running   0          5d
calico-kube-controllers-67890        1/1     Running   0          5d

Vérifiez la configuration CNI dans le nœud si nécessaire, mais la balise d'image du pod révèle souvent la version :

kubectl get ds -n kube-system calico-node -o jsonpath='{.spec.template.spec.containers[0].image}'

Version de Kubernetes et disponibilité de l'API

NetworkPolicy est une API stable (networking.k8s.io/v1) depuis Kubernetes 1.7. Assurez-vous que votre cluster est suffisamment récent :

kubectl version --short

Exemple :

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.3

Politiques réseau existantes

Listez toutes les politiques réseau dans tous les espaces de noms pour comprendre votre état actuel :

kubectl get networkpolicies -A

Exemple de sortie :

NAMESPACE     NAME                   POD-SELECTOR       AGE
default       deny-all               <none>             10d
kube-system   allow-dns              app=kube-dns       10d
app-ns        allow-frontend-tiers   tier=frontend      2d

Notez les politiques de refus par défaut et leurs sélecteurs. C'est votre base de référence.

Outils de surveillance disponibles

Vérifiez si Prometheus est installé :

kubectl get pods -n monitoring | grep prometheus

Si ce n'est pas le cas, vous devrez peut-être installer Prometheus et le configurer pour collecter les métriques de votre CNI ou utiliser un ServiceMonitor.

Question rapide 1 sur 2

Quel est le comportement par défaut de la communication de Pod à Pod dans un cluster Kubernetes ?

Le passage de référence [1] indique : « Par défaut, tous les Pods d'un cluster Kubernetes sont autorisés à communiquer entre eux, et tout le trafic réseau n'est pas chiffré. »

Chemin de configuration sûr

La surveillance des politiques réseau doit être effectuée de manière incrémentale pour éviter de perturber le trafic de production. Suivez un chemin sûr : observer, activer les métriques, tester, puis alerter.

Étape 1 : Activer la collecte de métriques depuis le CNI

La plupart des CNI exposent des métriques Prometheus. Pour Calico, l'agent Felix (exécuté sur chaque nœud) fournit des métriques détaillées sur les politiques. Activez le rapport de métriques en appliquant la configuration suivante s'il n'est pas déjà activé.

Pour Calico, vous pouvez utiliser la FelixConfiguration intégrée :

apiVersion: crd.projectcalico.org/v1
kind: FelixConfiguration
metadata:
  name: default
spec:
  prometheusMetricsEnabled: true
  prometheusMetricsPort: 9091

Appliquez avec kubectl apply -f felix-config.yaml. Vérifiez en contrôlant le port Felix d'un nœud :

kubectl get felixconfigurations default -o yaml | grep prometheus

Pour Cilium, les métriques sont activées par défaut, mais vérifiez :

kubectl -n kube-system exec ds/cilium -- cilium status | grep Metrics

Étape 2 : Créer un ServiceMonitor pour Prometheus

Si vous utilisez Prometheus Operator, créez un ServiceMonitor pour collecter les métriques Felix :

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: calico-felix
  namespace: monitoring
spec:
  selector:
    matchLabels:
      k8s-app: calico-node
  endpoints:
  - port: metrics
    interval: 30s

Assurez-vous que le service calico-node expose le port des métriques. Sinon, créez un service :

apiVersion: v1
kind: Service
metadata:
  name: calico-node-metrics
  namespace: kube-system
  labels:
    k8s-app: calico-node
spec:
  selector:
    k8s-app: calico-node
  ports:
  - name: metrics
    port: 9091
    targetPort: 9091

Appliquez et vérifiez les cibles Prometheus :

kubectl -n monitoring port-forward svc/prometheus-operated 9090:9090
# Ensuite ouvrez http://localhost:9090/targets et confirmez que calico-felix est actif.

Étape 3 : Définir un trafic de test minimal

Avant de compter sur les alertes, générez un trafic connu qui doit être autorisé ou refusé par une politique de test. Créez un espace de noms de test et des pods :

kubectl create ns policy-test
kubectl run allowed-client --image=busybox --restart=Never -- sleep 3600
kubectl run denied-client --image=busybox --restart=Never -- sleep 3600
kubectl run server --image=nginx --restart=Never

Appliquez une NetworkPolicy qui autorise uniquement allowed-client à accéder à server :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-allow-specific
  namespace: policy-test
spec:
  podSelector:
    matchLabels:
      run: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          run: allowed-client
    ports:
    - port: 80

Testez maintenant la connectivité :

kubectl exec -it allowed-client -- wget -qO- --timeout=2 http://server
# Devrait renvoyer du HTML
kubectl exec -it denied-client -- wget -qO- --timeout=2 http://server
# Devrait échouer ou expirer

Cette base de référence permet de valider que les alertes correspondent au trafic réel.

Vérification et diagnostic

Une fois les métriques collectées et le trafic de test en cours, vous devez vérifier que l'application des politiques est visible et diagnostiquer tout problème.

Métriques clés à surveiller

Les différents CNI exposent des noms de métriques différents. Pour Calico Felix, les métriques importantes incluent :

felix_iptables_restore_errors : erreurs lors de l'application des règles iptables.
felix_denied_packets_total : nombre de paquets refusés par la politique (si l'action iptables est définie sur LOG).
felix_ipset_errors : erreurs de manipulation des jeux IP.
felix_active_local_endpoints : nombre de points de terminaison locaux.

Pour Cilium :

cilium_drop_count_total : paquets abandonnés en raison de la politique.
cilium_policy_endpoint_enforcement_status : état d'application par point de terminaison.

Exemples de requêtes dans Prometheus :

# Total des paquets refusés au cours des 5 dernières minutes
sum(increase(felix_denied_packets_total[5m]))

# Taux de pertes dans Cilium
sum(rate(cilium_drop_count_total[5m])) by (reason)

PromQL pour l'audit des politiques

Pour voir quels pods génèrent des refus, utilisez les étiquettes. Les métriques Calico incluent souvent des étiquettes comme source_namespace, source_pod, dest_namespace, dest_pod. Exemple :

topk(10, sum by (source_namespace, source_pod) (rate(felix_denied_packets_total[5m])))

Cela vous donne les principales sources de trafic refusé.

Utiliser kubectl pour inspecter l'état des politiques

Bien que les métriques du CNI montrent l'application, vous pouvez également inspecter les objets de politique et les points de terminaison :

kubectl describe networkpolicy test-allow-specific -n policy-test

La sortie comprend le sélecteur de pod et les règles d'entrée. Pour voir si une politique est appliquée à un pod, vérifiez les annotations du pod ou utilisez les outils CLI du CNI :

Pour Calico :

kubectl exec -n kube-system calicoctl -- calicoctl get profile -A

Pour Cilium, utilisez cilium endpoint list pour voir l'état d'application des politiques :

kubectl -n kube-system exec ds/cilium -- cilium endpoint list

Recherchez la colonne Policy enforcement : Ingress, Egress ou Both.

Diagnostiquer les problèmes de connectivité

Si le trafic est bloqué de manière inattendue, suivez cette séquence :

Vérifiez si une NetworkPolicy existe et sélectionne le pod :

   kubectl get networkpolicy -n <namespace>

Décrivez la politique et vérifiez les règles :

   kubectl describe networkpolicy <name> -n <namespace>

Pour Calico Felix :

Testez avec un pod client connu (comme précédemment).
Vérifiez les métriques de refus : interrogez Prometheus pour les paquets refusés dans cet espace de noms.
Vérifiez les journaux du CNI :

   kubectl logs -n kube-system ds/calico-node -c calico-node --tail=50

Pour Cilium :

   kubectl -n kube-system logs ds/cilium --tail=50

Question rapide 2 sur 2

Par quoi est-il recommandé de commencer lorsqu'une isolation réseau stricte entre locataires est requise ?

Le passage de référence [1] indique : « Dans un environnement multi-locataires où une isolation réseau stricte entre locataires est requise, il est recommandé de commencer par une politique par défaut qui refuse la communication entre les Pods, avec une autre règle qui permet à tous les Pods d'interroger le serveur DNS pour la résolution de noms. »

Modes de défaillance et récupération

La surveillance elle-même peut échouer, et les politiques peuvent provoquer des pannes involontaires. Cette section couvre les modes de défaillance courants et comment récupérer en toute sécurité.

Scénarios de défaillance typiques

1. Politique réseau trop restrictive

Une nouvelle politique peut bloquer le DNS ou les contrôles de santé, empêchant les pods de réussir les sondes de préparation. Symptôme : les pods restent bloqués en ContainerCreating ou ne sont pas prêts.

Vérifiez les événements du pod :

kubectl describe pod <pod-name> -n <namespace>

Si les événements montrent une connexion refusée vers kube-dns ou similaire, la politique bloque probablement le DNS. Récupération rapide : supprimez ou modifiez la politique pour autoriser le DNS (port 53) vers kube-dns.

Exemple de correction : appliquez une règle de sortie pour le DNS :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: myapp
spec:
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53
  policyTypes:
  - Egress

2. Point de terminaison de métriques non collecté

Si Prometheus ne peut pas collecter les métriques Felix, les alertes ne se déclencheront pas. Vérifiez les cibles Prometheus pour les erreurs :

https://prometheus.example.com/targets

Problèmes courants : étiquettes de service non concordantes, politique réseau bloquant Prometheus ou ServiceMonitor manquant. Corrigez en alignant les étiquettes dans ServiceMonitor et Service, et assurez-vous que Prometheus peut atteindre le port des métriques.

3. Bruit de journalisation dû aux paquets refusés

Si vous activez la journalisation iptables pour les paquets refusés (via FelixConfiguration logSeverityScreen ou similaire), les journaux peuvent être submergés. Définissez des niveaux de journalisation appropriés et faites pivoter les journaux. Surveillez votre pipeline de journaux.

Procédures de récupération

Restaurer une politique réseau

Sauvegardez toujours les politiques avant de les modifier. Utilisez kubectl get networkpolicy <name> -n <ns> -o yaml > policy-backup.yaml. Pour restaurer, appliquez la sauvegarde.

Désactiver temporairement l'application

Si une politique provoque une panne, vous pouvez la supprimer rapidement :

kubectl delete networkpolicy <name> -n <namespace>

Mais pour plus de sécurité, vous pouvez annoter la politique pour désactiver l'application si le CNI le prend en charge. Pour Calico, vous pouvez définir l'ordre de la politique ou utiliser applyOnForward ? Tous les CNI ne le prennent pas en charge. La suppression est souvent la plus rapide.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour assurer une surveillance continue et une réponse rapide.

Vérifications quotidiennes

[ ] La cible Prometheus calico-felix est active (ou l'équivalent de votre CNI).
[ ] Aucune alerte critique ne se déclenche pour les refus de politique ou les erreurs.
[ ] Les pods du CNI sont en cours d'exécution et ne redémarrent pas fréquemment.

Commande :

kubectl get pods -n kube-system | grep -E 'calico|cilium|antrea|weave'

Vérifications hebdomadaires

[ ] Examinez les principales sources de trafic refusé avec PromQL et vérifiez si elles sont légitimes.
[ ] Auditez les modifications de NetworkPolicy : kubectl get events --all-namespaces | grep NetworkPolicy.
[ ] Vérifiez le stockage Prometheus et la durée de collecte pour éviter les problèmes de performances.

Lorsqu'une nouvelle NetworkPolicy est appliquée

Avant d'appliquer, simulez le trafic attendu avec un pod de test.
Appliquez la politique dans un espace de noms de staging si possible.
Surveillez les métriques pour détecter des refus inattendus pendant la première heure.
Ayez un plan de restauration : sauvegardez le YAML.

Runbook d'alerte : trafic refusé élevé

Exemple de définition d'alerte (règle Prometheus) :

groups:
- name: network-policy
  rules:
  - alert: HighDeniedTraffic
    expr: sum(rate(felix_denied_packets_total[5m])) > 100
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Taux élevé de paquets refusés"
      description: "Le taux de paquets refusés est de {{ $value }} par seconde. Enquêtez sur les éventuelles mauvaises configurations."

Étapes du runbook :

Vérifiez Prometheus pour identifier les principaux espaces de noms et pods à l'origine des refus.
Si le trafic est légitime, ajustez la NetworkPolicy pour l'autoriser.
Si le trafic est malveillant, enquêtez sur la source et envisagez des mesures de sécurité supplémentaires.
Si c'est du bruit, ajustez la journalisation ou le seuil d'alerte.

Conclusion

La surveillance des politiques réseau Kubernetes est cruciale pour maintenir un cluster sécurisé et fiable. En tirant parti des métriques du CNI, de Prometheus et d'alertes bien définies, vous pouvez détecter rapidement les mauvaises configurations, résoudre les problèmes de connectivité et garantir que les politiques sont appliquées comme prévu. Ce guide a fourni des étapes concrètes pour l'inventaire de l'environnement, la configuration sûre, la vérification, la récupération en cas de défaillance et les listes de contrôle opérationnelles. Commencez par les bases : activez les métriques, créez un tableau de bord et configurez des alertes simples. Ensuite, itérez pour affiner votre surveillance à mesure que vos politiques évoluent. N'oubliez pas que l'objectif n'est pas seulement d'appliquer des politiques, mais de comprendre leur impact sur vos applications et de répondre efficacement lorsque les choses tournent mal.