Définir des règles d'entrée (Ingress) et de sortie (Egress)

Contrôler le trafic entrant : les règles Ingress

Les règles Ingress définissent quel trafic est autorisé à entrer dans les Pods ciblés par la Network Policy. Si la section `ingress` est définie dans une politique s'appliquant à un Pod, celui-ci n'acceptera que le trafic entrant qui correspond à au moins une des règles `ingress` spécifiées. Tout autre trafic entrant sera bloqué.

Une règle `ingress` est typiquement composée de deux parties principales :

• from : Spécifie les sources autorisées à initier la connexion vers les Pods ciblés. Une source peut être définie par :
  • podSelector : Autorise le trafic provenant de Pods (dans le même namespace ou un autre) correspondant à ce sélecteur de labels.
  • namespaceSelector : Autorise le trafic provenant de n'importe quel Pod situé dans un namespace correspondant à ce sélecteur de labels.
  • ipBlock : Autorise le trafic provenant d'une plage d'adresses IP spécifiée (en notation CIDR). Ceci est utile pour autoriser le trafic depuis l'extérieur du cluster ou depuis des composants d'infrastructure spécifiques.
  Si la clause from est omise ou vide dans une règle, elle autorise le trafic depuis n'importe quelle source (dans les limites des autres clauses de la règle, comme les ports). Si la section ingress entière est vide (ingress: []), aucun trafic entrant n'est autorisé.
• ports : Spécifie les ports et protocoles sur lesquels les Pods ciblés sont autorisés à recevoir du trafic. Chaque élément de cette liste peut définir :
  • protocol : Le protocole (TCP, UDP, SCTP). La valeur par défaut est TCP.
  • port : Le numéro de port spécifique ou un port nommé défini dans les conteneurs du Pod.
  Si la clause ports est omise ou vide, la règle s'applique à tous les ports.

Les différentes sources spécifiées dans la clause from d'une même règle sont combinées par un OU logique (le trafic est autorisé s'il provient de l'une des sources). De même, si plusieurs règles sont définies dans la section ingress, le trafic entrant est autorisé s'il correspond aux critères d'au moins une de ces règles.

Contrôler le trafic sortant : les règles Egress

Symétriquement aux règles Ingress, les règles Egress définissent quel trafic est autorisé à sortir des Pods ciblés par la Network Policy. Si la section `egress` est définie pour un Pod, celui-ci ne pourra initier des connexions sortantes que si elles correspondent à au moins une des règles `egress` spécifiées. Tout autre trafic sortant sera bloqué.

Une règle `egress` est structurée de manière similaire à une règle `ingress` :

• to : Spécifie les destinations autorisées pour les connexions sortantes initiées par les Pods ciblés. Comme pour from, une destination peut être définie par :
  • podSelector : Autorise le trafic vers des Pods (dans le même namespace ou un autre) correspondant à ce sélecteur.
  • namespaceSelector : Autorise le trafic vers n'importe quel Pod dans un namespace correspondant à ce sélecteur.
  • ipBlock : Autorise le trafic vers une plage d'adresses IP spécifiée (utile pour accéder à des services externes au cluster).
  Si la clause to est omise ou vide dans une règle, elle autorise le trafic vers n'importe quelle destination (soumis aux contraintes de ports). Si la section egress entière est vide (egress: []), aucun trafic sortant n'est autorisé.
• ports : Spécifie les ports et protocoles de destination vers lesquels les Pods ciblés sont autorisés à envoyer du trafic. La structure est identique à celle des règles `ingress` (protocol et port). Si omis ou vide, la règle s'applique à tous les ports de destination.

Comme pour Ingress, les différentes destinations de la clause to sont combinées par un OU logique, et plusieurs règles dans la section egress permettent le trafic sortant s'il correspond à au moins une d'entre elles.

Exemple simple combinant Ingress et Egress

Voici un exemple de Network Policy qui cible les Pods avec le label `app=backend` dans le namespace `production` :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: database
    ports:
    - protocol: TCP
      port: 5432
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns # Autorise la résolution DNS
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Cette politique stipule que les Pods `backend` :

• (Ingress) Peuvent recevoir du trafic TCP sur le port 8080 uniquement depuis les Pods ayant le label `app=frontend` dans le même namespace (`production`).
• (Egress) Peuvent envoyer du trafic TCP sur le port 5432 uniquement vers les Pods ayant le label `role=database` dans le même namespace.
• (Egress) Peuvent également envoyer du trafic UDP et TCP sur le port 53 vers les Pods `kube-dns` dans le namespace `kube-system` pour permettre la résolution DNS.

Tout autre trafic entrant ou sortant pour les Pods `backend` sera bloqué.