Comprendre la sécurité du réseau dans GKE

Ce document explique les concepts de base de la sécurité réseau GKE, tels que le principe du moindre privilège, et vous aide à choisir les bons outils pour sécuriser votre cluster. Les principaux objectifs de l'implémentation de la sécurité réseau GKE sont l'isolation des charges de travail et la mutualisation sécurisée. Pour atteindre ces objectifs, vous devez appliquer les principes du moindre privilège et de la défense en profondeur, et utiliser des données exploitables pour éclairer vos décisions en matière de sécurité.

Dans Google Kubernetes Engine (GKE), appliquer le principe du moindre privilège au trafic réseau signifie limiter la communication à ce qui est nécessaire au fonctionnement de vos applications. Par défaut, le réseau d'un cluster GKE est ouvert, ce qui signifie que chaque pod peut communiquer avec tous les autres pods.

Ce document aide les opérateurs, les spécialistes de la mise en réseau et les spécialistes de la sécurité à comprendre et à mettre en œuvre la sécurité du réseau dans les clusters GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches dans Google Cloud, consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire ce document, assurez-vous de connaître les éléments suivants :

  • Concepts de mise en réseau GKE : pour obtenir une présentation, consultez À propos de la mise en réseau GKE.
  • Pods, services et espaces de noms Kubernetes : ces ressources Kubernetes fondamentales sont essentielles pour définir les règles de sécurité du réseau. Consultez la documentation Kubernetes.
  • Principe du moindre privilège : ce principe de sécurité est un concept de base appliqué tout au long de ce document.

Objectifs de la sécurité réseau GKE

Les règles de sécurité réseau GKE permettent de contrôler précisément le trafic dans votre cluster, en tenant compte de Kubernetes. Ces règles sont un élément essentiel de votre stratégie de sécurité globale. Pour implémenter une sécurité réseau robuste, tenez compte des principes fondamentaux suivants :

  • Moindre privilège : n'accordez aux systèmes et services que les privilèges minimaux requis pour exécuter leurs fonctions. Ce principe réduit l'impact potentiel d'une compromission. Les règles de réseau Kubernetes vous aident à passer d'un réseau ouvert par défaut à un réseau où seules les connexions nécessaires sont autorisées.
  • Défense en profondeur : superposez plusieurs contrôles de sécurité indépendants. Une défaillance dans un contrôle n'entraîne pas une compromission totale du système. Par exemple, vous utilisez une règle réseau pour isoler une base de données, même si la base de données elle-même nécessite une authentification.
  • Données exploitables : basez vos décisions de sécurité sur les données. La modélisation des menaces et l'évaluation des risques vous permettent de définir votre stratégie de sécurité. Des fonctionnalités telles que la journalisation des règles de réseau fournissent les données permettant de vérifier les règles et de détecter les éventuelles violations.

Choisir une stratégie de sécurité réseau

Pour choisir la bonne règle, identifiez le type et le champ d'application du trafic que vous devez contrôler.

Types de trafic

Pour choisir la bonne règle, tenez compte de la source et de la destination du trafic que vous souhaitez gérer :

  • Communication entre les pods au sein du cluster : pour contrôler la façon dont les microservices communiquent entre eux, utilisez des règles qui fonctionnent sur les libellés et les espaces de noms des pods.

    • En tant que développeur d'applications, utilisez le NetworkPolicy Kubernetes standard pour définir les règles d'entrée et de sortie de votre application dans son espace de noms.
    • En tant qu'administrateur de cluster, utilisez CiliumClusterwideNetworkPolicy pour appliquer des garde-fous de sécurité qui s'appliquent à l'ensemble du cluster. Les règles de refus dans NetworkPolicy prévalent sur les règles d'autorisation CiliumClusterwideNetworkPolicy.

  • Trafic sortant des pods vers les services externes : pour contrôler le trafic sortant des pods vers les services externes en fonction des noms de domaine, utilisez FQDNNetworkPolicy. Cette règle est utile lorsque les adresses IP des services externes ne sont pas statiques, car elle résout et met à jour automatiquement les adresses IP autorisées en fonction du DNS.

  • Chiffrement de tout le trafic entre services : pour vous assurer que toutes les communications entre les services sont chiffrées et authentifiées, utilisez un maillage de services. Utilisez Istio ou Anthos Cloud Service Mesh pour implémenter le protocole TLS mutuel (mTLS), qui gère automatiquement le chiffrement.

Récapitulatif des choix concernant les règles

Le tableau suivant récapitule la stratégie à utiliser en fonction de votre objectif de sécurité.

Objectif Règle recommandée
Contrôlez le trafic entre les pods à l'aide de libellés et d'espaces de noms. Kubernetes NetworkPolicy
Contrôlez le trafic sortant vers les services externes par nom de domaine. FQDNNetworkPolicy
Chiffrez et authentifiez tout le trafic de service à service. Istio ou Anthos Cloud Service Mesh (pour mTLS)
Appliquez des règles obligatoires à l'ensemble du cluster en tant qu'administrateur. CiliumClusterwideNetworkPolicy
Auditez et enregistrez les connexions autorisées ou refusées par les règles. Journalisation des règles de réseau (activée pour toutes les règles)

Auditer et dépanner les règles réseau

Après avoir implémenté des règles de réseau, vérifiez qu'elles fonctionnent comme prévu et diagnostiquez les éventuels problèmes de connectivité. Vous pouvez utiliser la journalisation des règles de réseau comme outil principal.

Lorsque vous activez la journalisation des règles de réseau, GKE génère un enregistrement de journal dans Cloud Logging pour chaque connexion qu'une règle de réseau autorise ou refuse. Ces journaux sont essentiels pour effectuer des audits de sécurité et résoudre les problèmes liés à un comportement inattendu. L'examen de ces journaux vous permet de constater les effets concrets de vos règles, en confirmant que le trafic légitime circule comme prévu et que le trafic non autorisé est bloqué.

Étapes suivantes