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 la mise en œuvre 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 prendre 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é réseau dans les clusters GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches dans Cloud de Confiance by S3NS, consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire ce document, assurez-vous de bien 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 des règles de sécurité 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 offrent un contrôle précis du trafic dans votre cluster, compatible avec Kubernetes. Ces règles sont un élément essentiel de votre stratégie de sécurité globale. Pour mettre en œuvre une sécurité réseau robuste, tenez compte des principes fondamentaux suivants :

• Moindre privilège : n'accordez aux systèmes et aux 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 de 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 des données. La modélisation des menaces et l'évaluation des risques éclairent votre stratégie de sécurité. Des fonctionnalités telles que la journalisation des règles de réseau fournissent les données nécessaires pour vérifier les règles et détecter les violations potentielles.

Choisir une règle de sécurité réseau

Pour choisir la bonne règle, identifiez le type et la portée 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 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 la Kubernetes NetworkPolicy pour définir des règles d'entrée et de sortie pour votre application dans son espace de noms.
  • En tant qu'administrateur de cluster, utilisez le CiliumClusterwideNetworkPolicy pour appliquer des garde-fous de sécurité qui s'appliquent à l'ensemble du cluster. Les règles de refus de NetworkPolicy sont prioritaires sur les CiliumClusterwideNetworkPolicy règles d'autorisation.

• Trafic sortant des pods vers des services externes : pour contrôler le trafic sortant des pods vers des 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 automatiquement à jour les adresses IP autorisées en fonction du DNS.

• Chiffrement pour tout le trafic de service à service : 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ésumé des choix de règles

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

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

Après avoir mis en œuvre des règles de réseau, vérifiez qu'elles fonctionnent comme prévu et diagnostiquez les 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 autorisée ou refusée par une règle de réseau. Ces journaux sont essentiels pour effectuer des audits de sécurité et résoudre les comportements inattendus. L'examen de ces journaux vous permet de voir les effets concrets de vos règles, de confirmer que le trafic légitime circule comme prévu et que le trafic non autorisé est bloqué.

Étape suivante

• Découvrez comment configurer une Kubernetes NetworkPolicy.
• Découvrez comment contrôler le trafic sortant à l'aide d'une FQDNNetworkPolicy.
• Découvrez comment configurer CiliumClusterwideNetworkPolicy pour les règles à l'échelle du cluster.
• Découvrez comment activer la journalisation des règles de réseau pour auditer vos règles.