04. Réseau

Le modèle choisi : une politique par cible#

Il y a deux façons d'écrire de la segmentation avec des NetworkPolicy, et le choix se paie différemment.

Le dépôt retient le second, et le dit : « Pas de default-deny global (plus sûr avec les pods CNPG, sensibles à la réplication) ». C'est un compromis assumé, pas une ignorance — et pour un cluster de démonstration dont l'objet est d'enseigner la segmentation, la lisibilité l'emporte.

La chaîne autorisée#

Les neuf politiques d'ingress#

Le fichier contient treize politiques : neuf pour l’ingress, quatre pour l’egress. Les autorisations de toutes les politiques sélectionnant un pod sont réunies ; il faut donc lire leur union, pas chaque fichier isolément. Pour une connexion, l’egress de la source et l’ingress de la destination doivent tous deux l’autoriser.

Trois détails que la lecture rapide manque :

• Prometheus est autorisé à joindre l'API. Il scrape /metrics sur le port 8000. Sans cette source dans allow-api, la supervision tomberait silencieusement en même temps que la segmentation serait activée.
• RabbitMQ doit pouvoir se parler à lui-même. Un cluster à 3 nœuds a besoin d'epmd et du port de distribution Erlang entre ses membres, d'où une règle dont la source est… son propre label.
• Les opérateurs ont leur porte. CNPG (namespace cnpg-system) et l'opérateur RabbitMQ (rabbitmq-system) doivent atteindre leurs pods pour les gérer, sonder leur état et déclencher les bascules. Les oublier, c'est un cluster qui se fige dès la première panne.

Le cas qui porte la leçon : frontend → postgres#

C'est le seul refus que le dépôt met en avant, parce qu'il correspond à un vrai scénario d'attaque : un frontend compromis — exécution de code dans le conteneur nginx, image altérée — tenterait de joindre la base directement.

# k8s/network-policies.yaml
metadata: { name: allow-postgres }
spec:
  podSelector: { matchLabels: { cnpg.io/podRole: instance } }
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector: { matchLabels: { cnpg.io/cluster: task-manager-db } }
    - podSelector: { matchLabels: { job-name: db-migrate } }
    ports:
    - { protocol: TCP, port: 5432 }

frontend n'apparaît nulle part : la connexion est refusée par l'absence, pas par une règle de blocage explicite. Et le README du dépôt précise que ce n'est pas une supposition — « vérifié : un pod non listé sur la base time-out ; l'api passe ». Sur un projet dont la thèse est la preuve plutôt que l'affirmation, tester une politique réseau est la moindre des choses : une NetworkPolicy non appliquée par le CNI ne produit aucune erreur, juste une fausse impression de sécurité.

La Gateway : quatre objets là où l'Ingress n'en avait qu'un#

L'entrée du cluster est décrite en Gateway API, servie par Envoy Gateway. Le découpage est le cœur du sujet : là où un Ingress mélangeait tout dans un objet plus des annotations propriétaires, quatre ressources portent quatre décisions, qui n'appartiennent pas aux mêmes personnes.

# k8s/gateway.yaml — les ports ouverts, et qui peut s'y attacher
spec:
  gatewayClassName: eg
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces: { from: Same }

allowedRoutes limite ici l’attachement aux routes du namespace de la Gateway. Cela ne réserve pas globalement un hostname : une autre Gateway peut encore déclarer le même nom. Le contrôle multitenant dépend aussi des droits de création des Gateways, des classes autorisées et, si nécessaire, de règles d’admission.

# k8s/httproutes.yaml — l'application, sans hostname : elle attrape tout
spec:
  parentRefs:
  - { name: task-manager, sectionName: http }
  rules:
  - matches:
    - path: { type: PathPrefix, value: / }
    backendRefs:
    - { name: frontend, port: 80 }

Les identifiants de la console RabbitMQ ne sont écrits nulle part : l'opérateur les génère dans le secret rabbitmq-default-user. On les lit avec kubectl get secret rabbitmq-default-user -n task-manager -o jsonpath='{.data.username}' | base64 -d.

Comment le trafic entre, et pourquoi le label ingress-ready a disparu#

Envoy Gateway expose une Gateway par un Service LoadBalancer. Sur un cluster local, personne ne provisionne d'IP externe : le Service resterait en <pending> indéfiniment. On le bascule donc en NodePort figé, et Kind mappe ce port sur l'hôte.

# k8s/gateway.yaml — l'EnvoyProxy référencé par la GatewayClass
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        type: NodePort
        externalTrafficPolicy: Cluster    # <- indispensable, cf. ci-dessous
        patch:
          type: StrategicMerge
          value:
            spec:
              ports:
              - { port: 80, nodePort: 30080 }   # <- fusion sur la clé `port`

# k8s/kind-config.yaml
extraPortMappings:
- { containerPort: 30080, hostPort: 80, protocol: TCP }

Le patch fusionne sur port, la clé de fusion des ServicePort : on n'écrase que le nodePort, le nom généré par Envoy Gateway (http-80) survit. C'est le remplaçant typé des annotations nginx.ingress.kubernetes.io/* : un champ validé par une CRD, pas une chaîne de caractères interprétée par un contrôleur.

Une fois Cluster posé, le gain est plus grand qu'il n'y paraît. Un NodePort écoute sur tous les nœuds : le trafic entre par le control-plane, et kube-proxy l'achemine vers les pods Envoy où qu'ils soient. L'ancien montage — hostPort 80/443 plus un label ingress-ready=true ciblé par le nodeSelector du contrôleur — épinglait au contraire le point d'entrée sur le control-plane. Ce label était un artefact du provider Kind d'ingress-nginx, pas une notion Kubernetes ; il a disparu de kind-config.yaml, avec le nodeSelector et la toleration qui allaient avec.

Ingress, l'API historique#

Le dépôt a remplacé Ingress NGINX par Envoy Gateway. Le projet communautaire Ingress NGINX a annoncé sa retraite pour mars 2026 : voir la communication officielle Kubernetes. Cela ne retire ni l’API Ingress de Kubernetes, ni tous les autres contrôleurs basés sur nginx.

# l'ancien k8s/ingress.yaml, pour comparaison
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: { name: frontend, port: { number: 80 } }

C'est plus court, et c'est précisément le problème : tout ce qui n'entre pas dans ce moule — réécriture de chemin, timeouts, en-têtes, répartition de charge, mTLS — passait par des annotations propres à chaque contrôleur, non validées, non portables, et non documentées par l'API Kubernetes. Gateway API remonte ces réglages dans des ressources typées.

Il faut malgré tout connaître Ingress : c'est encore ce qu'on trouve dans l'immense majorité des clusters en service, et la migration est un exercice courant. Les correspondances utiles :

Le service du frontend : 80 dehors, 8080 dedans#

spec:
  selector: { app: frontend }
  ports:
  - port: 80          # ce que la HTTPRoute appelle
    targetPort: 8080  # ce que nginx-unprivileged écoute

L’image nginx-unprivileged écoute sur 8080 et le Service expose le port 80. Un processus non-root peut parfois utiliser un port inférieur à 1024 selon les capabilities et les paramètres du noyau ; 8080 évite de dépendre de cette configuration. La NetworkPolicy cible le port de destination du pod, donc 8080 ici.

À retenir#

• Une politique par cible : plus lisible et moins risqué qu'un default-deny global, au prix d'une sûreté par défaut moindre.
• Une politique Ingress ne verrouille que l'entrant. L'egress se ferme séparément, et il l'est désormais pour les workloads applicatifs (ch. 07).
• Ne pas oublier les sources non applicatives : Prometheus, le clustering RabbitMQ, et les opérateurs.
• Une NetworkPolicy non appliquée par le CNI échoue en silence : il faut la tester.
• Gateway API sépare ce que l'Ingress mélangeait : GatewayClass (l'implémentation), Gateway (les ports ouverts), HTTPRoute (les backends) — et allowedRoutes dit enfin qui a le droit de s'attacher.
• hostnames est au niveau de la route, pas de la règle : une HTTPRoute par hostname. C'est ce qui surprend le plus en migrant depuis un Ingress.
• Le point d'entrée est un NodePort figé mappé par Kind, pas un hostPort épinglé sur le control-plane : le label ingress-ready était un artefact d'ingress-nginx, il a disparu.
• externalTrafficPolicy décide qui peut servir un NodePort. Local — le défaut d'Envoy Gateway — préserve l'IP source mais n'accepte que les nœuds portant un pod ; Cluster masque et route partout. Sur Kind, seul Cluster fonctionne.
• Le durcissement se propage jusqu'au réseau : port 8080 non privilégié, donc targetPort: 8080 et une politique qui cible 8080.