Comprendre la sécurité du réseau Kubernetes

La mise en réseau est une partie particulièrement complexe de Kubernetes. Les réseaux peuvent être configurés de différentes manières. Vous pouvez utiliser un service mesh, mais pas forcément. Certaines ressources de votre cluster peuvent s’interfacer uniquement avec des réseaux internes, tandis que d’autres nécessitent un accès direct à Internet. Les ports, les adresses IP et les autres attributs du réseau sont généralement configurés de manière dynamique, ce qui peut rendre difficile le suivi de ce qui se passe au niveau du réseau.

En raison de ces complexités et d’autres, la sécurité du réseau Kubernetes peut ressembler à un parcours de combattant. Elle nécessite une compréhension approfondie de l’architecture réseau de Kubernetes ainsi qu’une bonne connaissance des outils que Kubernetes propose nativement pour aider à sécuriser les réseaux, tels que les politiques réseau et les outils tiers qui peuvent renforcer les réseaux.

Cet article présente les principes fondamentaux de la sécurité du réseau Kubernetes. Vous apprendrez comment les réseaux Kubernetes fonctionnent, quels risques de sécurité peuvent avoir un impact sur les ressources du réseau et quelles sont les meilleures pratiques à suivre pour sécuriser les réseaux dans Kubernetes.

Guide complet de la mise en réseau sur Kubernetes

La première étape pour sécuriser Kubernetes au niveau du réseau consiste à comprendre comment Kubernetes gère le réseau. C’est un vaste programme, mais voici les principes fondamentaux de la mise en réseau de Kubernetes que vous devez connaître.

Objectifs du réseau

Dans Kubernetes, les réseaux servent deux objectifs principaux :

Réseaux internes : les réseaux gèrent le trafic interne qui facilite les communications entre les pods, les nœuds et les autres ressources d’un cluster. En général, les réseaux internes utilisent des sous-réseaux et des adresses IP privés, et sont isolés de l’Internet public.
Réseaux externes : les workloads qui doivent se connecter à Internet utilisent des adresses IP publiques.

Kube-Proxy

Le service qui gère les flux de trafic au sein de Kubernetes est kube-proxy. Kube-proxy s’exécute sur chaque nœud d’un cluster Kubernetes et transmet les paquets aux containers hébergés sur ces nœuds en fonction des adresses IP et des ports des containers.

En arrière-plan, kube-proxy s’appuie sur des services réseau au niveau de l’OS, comme iptables sous Linux, pour contrôler le trafic. Mais comme kube-proxy résume ces services depuis des ressources Kubernetes, la couche de gestion réseau sous-jacente au niveau du nœud n’est pas particulièrement importante du point de vue de la sécurité du réseau Kubernetes.

Plugins CNI

Dans la plupart des cas, Kubernetes utilise un plugin CNI (Container Network Interface) pour créer une interface réseau virtuelle que les containers peuvent utiliser. Les plugins CNI peuvent être utilisés pour intégrer Kubernetes à diverses plates-formes tierces de gestion de la configuration réseau, telles que celles qui fonctionnent nativement sur les clouds publics (comme Azure Virtual Networks et AWS Network Interfaces).

Des plugins CNI sont également disponibles pour prendre en charge des plateformes telles que Project Calico et Weave Net, qui sont conçues pour offrir un moyen de normaliser les configurations de mise en réseau dans des environnements hétérogènes ou hybrides (c’est-à-dire des environnements qui combinent plusieurs types de plateformes, comme Kubernetes et un cloud public ou un centre de données privé).

Bien qu’il soit techniquement possible de configurer le réseau dans Kubernetes sans utiliser de plugin CNI, la plupart des clusters de production utilisent des CNI pour gérer le réseau.

Services Mesh

Outre les plugins CNI, les clusters Kubernetes de production s’appuient généralement sur un service Mesh pour simplifier la mise en réseau. Les services Mesh automatisent la découverte de différentes ressources sur un réseau. La plupart des services Mesh offrent également des fonctionnalités d’observabilité et de sécurité du réseau.

Kubernetes lui-même ne fournit pas de services Mesh natifs, mais il peut s’intégrer à la plupart des services Mesh courants, comme Istio, Traefik et NGINX.

Configurations dynamiques

Quels que soient le plugin CNI, les services Mesh et les autres outils de mise en réseau que vous choisissez d’utiliser avec Kubernetes, vos configurations réseau seront presque toujours très dynamiques.

En d’autres termes, les adresses IP et les ports des nœuds, des pods et des services sont configurés à la volée, lors de la création de ces ressources. Bien que les administrateurs puissent définir des pools d’adresses IP que Kubernetes utilisera pour effectuer les affectations, vous ne pouvez pas attribuer d’adresses IP statiques (du moins pas avec l’outil natif de Kubernetes).

Les configurations dynamiques rendent la sécurité du réseau Kubernetes plus difficile à certains égards. Vous ne pouvez pas, par exemple, établir de liste blanche ou de liste noire d’hôtes sur la base de configurations d’adresses statiques, comme vous pourriez le faire en travaillant avec des machines virtuelles. Il peut également être plus difficile de faire correspondre les données de trafic réseau à des ressources spécifiques dans Kubernetes, car vous ne pouvez pas toujours savoir si une adresse IP donnée a été utilisée par un seul pod ou nœud, par exemple, ou si elle a été utilisée par une ressource, puis réaffectée à une autre lorsque la première s’est arrêtée.

Comment sécuriser les ressources réseau de Kubernetes ?

Étant donné que Kubernetes s’appuie généralement sur un mélange de ressources internes (comme kube-proxy) et de services externes (comme les plugins CNI et les services Mesh) pour gérer les configurations et le trafic réseau, la sécurisation des réseaux Kubernetes nécessite également que les administrateurs exploitent un mélange d’outils natifs et tiers.

Définir les politiques réseau

En natif, la ressource la plus importante que Kubernetes offre pour la sécurité du réseau est la politique réseau. En termes simples, les politiques réseau définissent les règles qui régissent la manière dont les pods peuvent communiquer entre eux au niveau du réseau.

En plus de fournir un moyen systématique de contrôler les communications entre pods, les politiques réseau offrent l’avantage important de permettre aux administrateurs de définir les ressources et les règles de réseau associées en fonction du contexte, comme les étiquettes et les namespaces des pods. C’est crucial car, comme nous l’avons expliqué plus haut, vous ne pouvez pas utiliser les adresses IP pour gérer les règles du réseau, étant donné la nature dynamique des configurations réseau de Kubernetes.

Les politiques réseau sont similaires aux politiques RBAC de Kubernetes. Il s’agit de fichiers qui spécifient les règles de mise en réseau que vous souhaitez appliquer, et qui identifient également les ressources (un namespace, un pod, etc.) auxquelles les règles s’appliquent.

Par exemple, cette politique réseau empêche la sortie du backend entre les pods exécutant le namespace « par défaut » :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-backend-egress
  namespace: default
  spec:
    podSelector:
    matchLabels:
      tier: backend
      policyTypes:
      - Egress
      egress:
      - to:
        - podSelector:
        matchLabels:
        tier: backend

Limites des politiques réseau

Si les politiques réseau sont un outil crucial pour la sécurité du réseau Kubernetes, il est important de reconnaître leurs limites :

Elles se concentrent sur les pods : les politiques réseau sont essentiellement conçues pour isoler ou restreindre l’accès au réseau pour les pods. Vous ne pouvez pas les utiliser (du moins pas de manière directe et simple) pour gérer les règles de mise en réseau des nœuds ou d’autres ressources dans Kubernetes.
Elles ne détectent pas les abus : les politiques réseau sont un excellent moyen de verrouiller l’accès au réseau et de combler les failles de sécurité potentielles. Mais elles ne font rien pour détecter ou vous alerter de problèmes de sécurité potentiels.
Elles ne chiffrent pas les données : les politiques réseau ne peuvent pas chiffrer les données en mouvement lorsqu’elles se déplacent entre les composants de Kubernetes. Vous devrez utiliser des outils tiers (comme un service Mesh) pour réaliser le chiffrement du réseau.

Tirez parti des outils de sécurité du réseau tiers

En ce qui concerne les outils de sécurité réseau natifs de Kubernetes, les politiques réseau sont les seuls outils disponibles. Pour aborder d’autres facettes de la sécurité du réseau, vous devrez vous appuyer sur des outils externes.

Comme les outils et les fonctions de sécurité spécifiques disponibles auprès de diverses solutions de mise en réseau tierces pour Kubernetes varient, il n’existe pas de solution unique pour répondre aux exigences de sécurité du réseau par le biais d’outils externes.

En général, cependant, les services Mesh vous permettront de chiffrer le trafic, d’appliquer l’authentification et l’autorisation pour les ressources connectées au réseau, et de collecter des données de télémétrie à partir des ressources du réseau Kubernetes, que vous pouvez à votre tour alimenter dans des plateformes d’analyse de la sécurité pour aider à détecter les brèches. Certains services Mesh fournissent également des frameworks de politiques que vous pouvez utiliser pour appliquer des règles de sécurité réseau qui ne sont pas pratiques à l’aide des politiques réseau de Kubernetes, comme l’isolement des namespaces ou le refus des connexions si la sécurité de la couche transport n’est pas présente.

Les plugins CNI fournissent souvent des types de fonctionnalités similaires, notamment des frameworks de politiques et des fonctionnalités de surveillance du réseau. Ainsi, selon l’outil spécifique que vous préférez utiliser, vous pouvez choisir de vous appuyer principalement sur votre plateforme réseau connectée à CNI ou sur votre service Mesh pour fournir la visibilité et l’application des politiques nécessaires pour maximiser la sécurité du réseau Kubernetes.

Suivez les meilleures pratiques de sécurité de Kubernetes

Au-delà de l’exploitation des divers outils disponibles pour aider à sécuriser les réseaux Kubernetes, il existe des bonnes pratiques standard à suivre lorsque l’on travaille avec les ressources réseau en général dans un environnement qui héberge un cluster Kubernetes.

Utilisez RBAC : bien que le contrôle d’accès basé sur les rôles (RBAC) de Kubernetes ne soit pas un framework de sécurité réseau, les règles RBAC peuvent contribuer à atténuer l’impact des menaces véhiculées par le réseau en limitant leur accès aux ressources d’un cluster.
Évitez les ports par défaut : Kubernetes utilise des ports par défaut pour la plupart de ses services. Pour renforcer la sécurité du réseau, choisissez des ports personnalisés, ce qui rendra plus difficile la localisation des ressources par les cybercriminels.
Segmentez les réseaux en externe : si vous pouvez (et devez) utiliser des politiques réseau, des règles de services Mesh et d’autres ressources pour isoler les réseaux à l’intérieur de Kubernetes, vous pouvez obtenir une couche supplémentaire de sécurité réseau en segmentant également les réseaux externes. Selon l’endroit où vous hébergez vos clusters, cela signifie tirer parti de ressources telles que les VPC ou les pare-feu locaux pour réduire l’exposition des ressources à l’Internet public.
Tirez parti des journaux d’audit :les journaux d’audit de Kubernetes fournissent des enregistrements de chaque demande de ressource exécutée dans Kubernetes. En activant et en analysant les journaux d’audit, vous maximisez vos chances de détecter un comportement qui pourrait être le signe d’une brèche dans le réseau.