Exemples de politiques réseau (isolation par défaut, autorisation spécifique)

Mise en pratique : scénarios courants de Network Policies

Après avoir exploré la théorie des Network Policies, des règles Ingress/Egress et l'utilisation des sélecteurs, il est temps de voir comment les appliquer concrètement. Cette section présente des exemples de politiques réseau que vous rencontrerez fréquemment ou que vous pourrez adapter pour sécuriser votre cluster Kubernetes.

Nous allons nous concentrer sur deux stratégies fondamentales : l'isolation par défaut, qui consiste à bloquer tout trafic non explicitement autorisé, et l'autorisation spécifique, qui ouvre des canaux de communication précis entre les composants de vos applications.

Ces exemples utilisent les concepts vus précédemment et illustrent comment combiner `podSelector`, `namespaceSelector`, `policyTypes`, `ingress`, `egress`, et `ports` pour atteindre des objectifs de sécurité réseau précis.

Politique d'isolation par défaut (Default Deny)

L'une des pratiques de sécurité les plus recommandées est d'établir une politique d'isolation par défaut au niveau d'un namespace. Cela signifie qu'aucun trafic (entrant et/ou sortant) n'est autorisé pour les Pods de ce namespace, à moins qu'une autre politique ne l'autorise explicitement.

1. Refuser tout le trafic entrant (Deny All Ingress) :

Cette politique empêche tous les Pods du namespace 'secure-ns' de recevoir du trafic, quelle qu'en soit la source.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: secure-ns
spec:
  podSelector: {} # S'applique à tous les pods du namespace
  policyTypes:
  - Ingress
  # Pas de section 'ingress', donc aucun trafic entrant n'est autorisé.

2. Refuser tout le trafic sortant (Deny All Egress) :

Cette politique empêche tous les Pods du namespace 'secure-ns' d'initier des connexions vers l'extérieur.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: secure-ns
spec:
  podSelector: {}
  policyTypes:
  - Egress
  # Pas de section 'egress', donc aucun trafic sortant n'est autorisé.

3. Refuser tout le trafic (Deny All Ingress and Egress) :

C'est la politique d'isolation la plus stricte, bloquant tout trafic entrant et sortant pour tous les Pods du namespace 'secure-ns'. C'est souvent le point de départ pour sécuriser un namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: secure-ns
spec:
  podSelector: {} # S'applique à tous les pods
  policyTypes:
  - Ingress
  - Egress
  # Pas de sections 'ingress' ou 'egress', donc tout est refusé.

Une fois une politique d'isolation par défaut en place, les Pods sont complètement isolés. Il faut ensuite créer d'autres Network Policies pour autoriser les flux nécessaires.

Autorisations spécifiques de trafic

Après avoir mis en place une politique de type 'default deny', ou même sans cela si vous souhaitez juste restreindre certains flux, vous créerez des politiques pour autoriser des communications spécifiques.

1. Autoriser le trafic entrant depuis un autre groupe de Pods :

Permet aux Pods avec le label `app=backend` de recevoir du trafic sur le port TCP 8080 uniquement depuis les Pods ayant le label `app=frontend` dans le même namespace ('webapp-ns').

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

2. Autoriser le trafic sortant vers un autre groupe de Pods :

Permet aux Pods `app=backend` d'initier des connexions vers les Pods `role=database` sur le port TCP 5432, toujours dans le namespace 'webapp-ns'.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-database
  namespace: webapp-ns
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: database
    ports:
    - protocol: TCP
      port: 5432

3. Autoriser le trafic sortant vers le DNS du cluster :

C'est une règle Egress très courante, souvent nécessaire même avec une politique 'default deny' en place, pour permettre aux Pods de résoudre les noms de service internes et externes. Elle cible tous les Pods (`podSelector: {}`) et autorise le trafic sortant vers les Pods DNS (souvent dans le namespace `kube-system` avec le label `k8s-app=kube-dns`) sur les ports UDP et TCP 53.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: webapp-ns # Ou le namespace concerné
spec:
  podSelector: {} # S'applique à tous les pods du namespace
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          # Ajustez si votre namespace système a un label différent
          kubernetes.io/metadata.name: kube-system 
      podSelector:
        matchLabels:
          k8s-app: kube-dns # Ou l'étiquette de votre service DNS (ex: coredns)
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

4. Autoriser le trafic sortant vers une IP externe :

Permet aux Pods `role=worker` d'accéder à une API externe située à l'adresse `198.51.100.10` sur le port HTTPS 443.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: worker-allow-external-api
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: worker
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 198.51.100.10/32 # /32 pour une seule IP
    ports:
    - protocol: TCP
      port: 443

Combinaison et bonnes pratiques

Rappelez-vous que les Network Policies sont additives. Si plusieurs politiques s'appliquent à un même Pod, le trafic (Ingress ou Egress) est autorisé s'il correspond aux règles d'au moins une de ces politiques. C'est ce qui permet de commencer par une politique 'default-deny-all' puis d'ajouter des politiques spécifiques pour 'ouvrir' les flux nécessaires.

Il est fortement recommandé d'adopter une approche 'default deny' pour les namespaces contenant des applications critiques ou sensibles. Pour les autres namespaces, vous pouvez choisir de ne restreindre que certains flux spécifiques sans bloquer tout par défaut.

Testez toujours vos politiques réseau attentivement, idéalement dans un environnement de non-production. Une politique mal configurée peut bloquer des communications légitimes et interrompre le fonctionnement de vos applications. Des outils comme `kubectl exec` dans un Pod pour tenter des connexions (`curl`, `nc`) peuvent aider à vérifier l'effet des politiques.

Enfin, une stratégie de labellisation claire et cohérente pour vos Pods et Namespaces est la clé pour écrire des Network Policies efficaces et maintenables. Sans labels pertinents, il devient très difficile de cibler précisément les Pods et de définir des règles de communication granulaires.