Sécurisation du trafic du cluster Kubernetes avec des stratégies de réseau de pod

Les pods Kubernetes peuvent communiquer librement entre eux par défaut. Cela pose un risque de sécurité lorsque votre cluster est utilisé pour plusieurs applications ou équipes. Un comportement errant ou un accès malveillant dans un pod peut diriger le trafic vers les autres pods de votre cluster.

Cet article vous apprendra comment éviter ce scénario en configurant politiques de réseau. Ces règles vous permettent de contrôler les flux de trafic Pod à Pod au niveau de l’adresse IP (couche OSI 3 ou 4). Vous pouvez définir avec précision les sources d’entrée et de sortie autorisées pour chaque pod.

Création d’une stratégie réseau

Les politiques de réseau sont créées en ajoutant NetworkPolicy objets à votre cluster. Chaque stratégie définit les pods auxquels elle s’applique et une ou plusieurs règles d’entrée et de sortie. Voici un manifeste de stratégie de base :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector:
    matchLabels:
      component: database
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            component: api
  egress:
    - to:
        - podSelector:
            matchLabels:
              component: api

Cette politique de réseau s’applique à tout pod avec un component: database étiquette dans le app espace de noms. Il indique que le trafic entrant (entrant) et sortant (sortant) n’est autorisé que depuis et vers les pods avec un component: api étiquette. Toutes les requêtes provenant d’autres pods, telles que component: web-frontendsera bloqué.

Les politiques de réseau peuvent être appliquées comme n’importe quel autre objet en utilisant Kubectl. Ils prendront effet immédiatement après leur création. Vous pouvez ajouter la politique de mise en réseau avant de démarrer les pods qu’elle sélectionne.

$ kubectl apply -f policy.yaml
networkingpolicy.networking.k8s.io/network-policy created

Fonctionnement des stratégies réseau

Les politiques de réseau sont mises en œuvre par les actifs de votre cluster greffon réseau. Vos politiques n’auront aucun effet si votre plugin ne prend pas en charge la fonctionnalité. Les options les plus populaires telles que Calicot et Cil livré avec la prise en charge de la stratégie réseau activée.

Lorsqu’une politique réseau s’applique à un pod, le plug-in inspecte son trafic pour vérifier qu’il est conforme aux exigences de la politique. Toutes les connexions qui ne répondent pas aux critères seront refusées. Le pod qui a tenté d’établir la connexion trouvera que l’hôte distant est inaccessible, soit parce qu’il tentait d’accéder à une ressource bloquée par une règle de sortie, soit parce qu’un pod distant a refusé la connexion entrante à l’aide d’une règle d’entrée.

Une connexion réussie entre deux pods ne peut être établie que lorsque les politiques de réseau sur tous les deux d’entre eux le permettent. La connexion peut être interdite par une règle de sortie du pod initiateur ou par une règle d’entrée sur la cible.

Les politiques de réseau sont toujours additif dans la nature. Lorsque plusieurs politiques sélectionnent le même pod, la liste des sources d’entrée et de sortie autorisées sera la combinaison de toutes les politiques.

Exemples de stratégies réseau

Les règles de réseau prennent en charge de nombreuses options différentes pour personnaliser les pods qu’elles ciblent et les types de connexion autorisés. Les exemples suivants présentent plusieurs cas d’utilisation courants.

Appliquez une politique à chaque pod dans l’espace de noms, en n’autorisant que le trafic entrant à partir d’un bloc d’adresses IP spécifique

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16

Le vide podSelector block signifie que tous les pods de l’espace de noms sont ciblés par la politique. La ipBlock limite le trafic entrant aux pods dont l’adresse IP se situe dans la plage spécifiée. Le trafic de sortie n’est pas bloqué.

Autoriser le trafic entrant à partir d’un bloc d’adresses IP, mais exclure certaines adresses IP spécifiques

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.0.1/24
              - 172.17.0.2/24
              - 172.17.0.3/24

ipBlock les règles prennent en charge un except pour exclure le trafic provenant de ou dirigé vers des adresses IP spécifiques.

Autoriser le trafic entrant de tous les pods de l’espace de noms, mais uniquement d’un port spécifique

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}
          ports:
            - protocol: TCP
              port: 443

La ports est disponible sur les règles d’entrée et de sortie. Il définit les ports à partir desquels le trafic peut être reçu et envoyé. Vous pouvez éventuellement spécifier une plage de ports, telle que 3000 – 3500, en définissant le endPort champ (3500) en plus de port (3000).

Autoriser le trafic provenant de pods avec une étiquette spécifique qui existent dans un espace de noms différent

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: database
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              application: demo-app
          podSelector:
            matchLabels:
              component: database

La politique stipule que tout pod étiqueté component: database peut atteindre tous les pods du database espace de noms, si son propre espace de noms est étiqueté demo-app.

Vous pouvez autoriser le trafic depuis tout les pods dans un espace de noms externe en créant une règle qui n’inclut qu’un namespaceSelector champ.

Autoriser explicitement tout le trafic

Parfois, vous souhaiterez peut-être autoriser explicitement tout le trafic d’un type particulier dans un espace de noms. Incluez le type dans votre stratégie, mais fournissez un sélecteur de pod vide et aucune règle :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - {}
  egress:
    - {}

Tous les pods de l’espace de noms peuvent communiquer librement, comme s’il n’y avait pas de politique. La création de la stratégie vous permet quand même d’indiquer vos intentions aux autres utilisateurs du cluster. Ils pourraient s’interroger sur la présence d’un espace de noms avec une mise en réseau illimitée dans un cluster qui a par ailleurs été sécurisé.

Quand utiliser les stratégies réseau

Des règles réseau doivent être créées pour chacun des espaces de noms et des pods de votre cluster. Cela isole mieux vos pods et vous permet de contrôler le flux de trafic.

Essayez de rendre vos politiques aussi précises que possible. Trop élargir l’accès, comme autoriser l’accès entre tous les pods d’un espace de noms, vous expose à des risques si l’un de vos conteneurs est compromis. Envisagez d’utiliser des sélecteurs précis pour identifier les télécommandes d’entrée et de sortie individuelles pour les pods sensibles tels que les services d’authentification, les bases de données et les gestionnaires de paiement.

Kubernetes n’active aucune politique réseau par défaut, ce qui peut permettre des oublis, même si vous souhaitez que tous les pods soient protégés par une politique. Vous pouvez atténuer ce risque en ajoutant une politique fourre-tout à vos espaces de noms. Cette politique sélectionne chaque pod dans l’espace de noms et applique une règle qui interdit toute communication réseau :

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

Les politiques de réseau sont toujours étendues aux espaces de noms, vous devrez donc créer un fourre-tout distinct pour chacun.

Sommaire

Kubernetes permet à tous les pods de votre cluster de communiquer entre eux. Ceci est trop permissif pour les applications du monde réel exécutées dans des clusters polyvalents. Les politiques de réseau résolvent ce problème en fournissant un système semblable à un pare-feu pour gérer les sources d’entrée et les cibles de sortie que chaque pod accepte.

Il est recommandé de configurer une politique réseau sur tous vos pods. Cela sécurisera votre cluster afin que seuls les flux de trafic légitimes soient autorisés. Cependant, les politiques de réseau ne sont qu’une partie de la sécurité de Kubernetes : d’autres mécanismes de protection tels que RBAC et Pod contextes de sécurité sont également des outils indispensables pour durcir votre environnement.