Bonnes pratiques de sécurité pour Cloud Service Mesh

Ce document décrit les bonnes pratiques à suivre pour établir et gérer une configuration Cloud Service Mesh sécurisée qui s'exécute sur Google Kubernetes Engine (GKE). Les conseils fournis dans ce document vont au-delà des paramètres utilisés pour configurer et installer Cloud Service Mesh. Ils décrivent comment utiliser Cloud Service Mesh avec d'autres produits et fonctionnalités Google Cloud pour vous protéger contre les menaces de sécurité auxquelles peuvent être confrontées les applications d'un maillage.

Ce document s'adresse aux administrateurs qui gèrent les stratégies dans Cloud Service Mesh et aux utilisateurs qui exécutent des services dans Cloud Service Mesh. Les mesures de sécurité décrites ici sont également utiles pour les organisations qui doivent renforcer la sécurité de leurs maillages de services afin de répondre aux exigences de conformité.

Le document est organisé comme suit :

Introduction

Cloud Service Mesh fournit des fonctionnalités et des outils qui vous aident à observer, gérer et sécuriser des services de manière unifiée. Il adopte une approche centrée sur les applications et utilise des identités d'application approuvées plutôt qu'une approche basée sur l'adresse IP du réseau. Vous pouvez déployer un maillage de services de manière transparente, sans avoir à modifier le code d'application existant. Cloud Service Mesh fournit un contrôle déclaratif sur le comportement du réseau, ce qui permet de dissocier le travail des équipes chargées de la livraison et de la publication des fonctionnalités d'application des responsabilités des administrateurs responsables de la sécurité et de la mise en réseau.

Cloud Service Mesh est basé sur le maillage de services Istio Open Source, qui permet des configurations et des topologies sophistiquées. Selon la structure de votre organisation, une ou plusieurs équipes ou rôles peuvent être chargés d'installer et de configurer un réseau maillé. Les paramètres par défaut de Cloud Service Mesh sont choisis pour protéger les applications, mais dans certains cas, vous devrez peut-être configurer des configurations personnalisées ou accorder des exceptions en empêchant certaines applications, certains ports ou adresses IP de participer à un maillage. Il est important de mettre en place des contrôles pour régir les configurations des réseaux maillés et les exceptions de sécurité.

Vecteurs d'attaque et risques de sécurité

Vecteurs d'attaque

La sécurité de Cloud Service Mesh suit le modèle de sécurité "zéro confiance" qui suppose que les menaces de sécurité proviennent de l'intérieur et de l'extérieur du périmètre de sécurité d'une organisation. Voici des exemples de types d'attaques de sécurité susceptibles de menacer les applications d'un maillage de services :

  • Les attaques par exfiltration de données Il peut s'agir, par exemple, d'attaques espionnant les données sensibles ou les identifiants émis par le trafic de service à service.
  • Les attaques MITM ("man in the middle"). Par exemple, un service malveillant qui se fait passer pour un service légitime pour obtenir ou modifier la communication entre les services.
  • Les attaques par élévation des privilèges. Il peut s'agir, par exemple, d'attaques utilisant un accès non autorisé à des privilèges élevés pour effectuer des opérations sur un réseau.
  • Les attaques par déni de service (DoS).
  • Les attaques Botnet, qui tentent de compromettre et de manipuler des services pour lancer des attaques sur d'autres services.

Les attaques peuvent également être classées en fonction des cibles des attaques :

  • Les attaques internes au réseau maillé. Les attaques visant à altérer, espionner ou usurper la communication service à service ou service à plan de contrôle interne au réseau maillé.
  • Les attaques au plan de contrôle. Les attaques visant à causer un dysfonctionnement du plan de contrôle (tel qu'une attaque DoS) ou à exfiltrer des données sensibles du plan de contrôle.
  • Les attaques en périphérie du réseau maillé. Les attaques visant à altérer, espionner ou usurper la communication au niveau de l'entrée ou de la sortie du réseau maillé.
  • Les attaques aux opérations du réseau maillé Les attaques visant les opérations du réseau maillé. Les pirates informatiques peuvent tenter d'obtenir des privilèges élevés pour effectuer des opérations malveillantes dans un réseau maillé, telles que la modification de ses règles de sécurité et de ses images de charge de travail.

Risques de sécurité

En plus des attaques de sécurité, un réseau maillé est également confronté à d'autres risques de sécurité. La liste suivante décrit quelques risques de sécurité possibles :

  • Protection de sécurité incomplète. Un maillage de services n'a pas été configuré avec des règles d'authentification et d'autorisation pour protéger sa sécurité. Par exemple, aucune règle d'authentification ou d'autorisation n'est définie pour les services d'un réseau maillé.
  • Exceptions aux règles de sécurité. Pour répondre à leurs cas d'utilisation spécifiques, les utilisateurs peuvent créer des exceptions aux règles de sécurité afin d'exclure certains trafics (internes ou externes) des règles de sécurité de Cloud Service Mesh. Pour gérer ces cas de manière sécurisée, consultez la section Gérer les exceptions aux règles de manière sécurisée.
  • Oubli des mises à niveau d'image. Des failles peuvent être détectées au niveau des images utilisées dans un réseau maillé. Vous devez maintenir le composant du réseau maillé et les images de charge de travail à jour avec les derniers correctifs de failles.
  • Faible maintenance (aucune expertise ou ressource). Les configurations du logiciel et des règles du réseau maillé nécessitent une maintenance régulière pour tirer parti des derniers mécanismes de protection de sécurité.
  • Manque de visibilité. Les erreurs de configuration ou des configuration non sécurisée des règles du réseau maillé, ainsi que le trafic ou les opérations de réseau maillé anormal(es) ne sont pas signalés aux administrateurs du réseau maillé.
  • Écarts de configuration. La configuration des règles dans un réseau maillé diffère de la source de vérité.

Mesures pour protéger un maillage de services

Cette section présente un manuel d'exploitation pour sécuriser les maillages de services.

Architecture de sécurité

La sécurité d'un maillage de services dépend de la sécurité des composants au niveau des différentes couches du système du réseau maillé et de ses applications. L'intention générale de la stratégie de sécurité proposée pour Cloud Service Mesh est de sécuriser un maillage de services en intégrant plusieurs mécanismes de sécurité à différentes couches, ce qui permet conjointement d'assurer la sécurité globale du système dans le cadre du modèle de sécurité zéro confiance. Le schéma suivant présente la stratégie de sécurité Cloud Service Mesh proposée.

stratégie de sécurité de Cloud Service Mesh

Cloud Service Mesh assure la sécurité à plusieurs couches, y compris:

  • Sécurité en périphérie du réseau maillé
    • La sécurité des entrées Cloud Service Mesh permet de contrôle des accès au trafic externe et de sécuriser l'accès externe aux API exposées par les services du maillage.
    • La sécurité de sortie de Cloud Service Mesh régule le trafic sortant des charges de travail internes.
    • L'authentification utilisateur Cloud Service Mesh s'intègre à l'infrastructure Google pour authentifier les appels externes provenant de navigateurs Web vers les services qui exécutent des applications Web.
    • La gestion des certificats de passerelle Cloud Service Mesh protège et assure la rotation des clés privées et des certificats X.509 utilisés par les passerelles d'entrée et de sortie Cloud Service Mesh qui utilisent Certificate Authority Service.
    • Cloud Armor peut vous protéger contre les attaques externes par déni de service distribué (DDoS) et de couche 7. Il sert de pare-feu d'application Web (WAF) pour protéger le réseau maillé contre les attaques de réseau. Il peut s'agir, par exemple, d'attaques par injection ou exécution de code à distance.
    • VPC et VPC Service Controls protègent le réseau périphérique via les contrôles des accès au réseau privé.
  • Sécurité du cluster
    • L'authentification TLS mutuelle (mTLS) de Cloud Service Mesh applique le chiffrement et l'authentification du trafic entre charges de travail.
    • Une autorité de certification gérée, telle que l'autorité de certification Cloud Service Mesh et Certificate Authority Service, provisionne et gère de manière sécurisée les certificats utilisés par les charges de travail.
    • L'autorisation Cloud Service Mesh applique le contrôle des accès aux services maillés en fonction de leur identité et d'autres attributs.
    • Le tableau de bord de sécurité GKE Enterprise permet de surveiller les configurations des règles de sécurité et des règles de réseau Kubernetes pour les charges de travail.
    • La règle de réseau Kubernetes applique un contrôle d'accès aux pods basé sur des adresses IP, des étiquettes de pods, des espaces de noms, etc.
    • La sécurité du plan de contrôle vous protège contre les attaques sur le plan de contrôle. Cette protection empêche les pirates informatiques de modifier, d'exploiter ou de divulguer des données de configuration du service et du réseau maillé.
  • Sécurité des charges de travail
    • Tenez-vous informé des versions de sécurité de Cloud Service Mesh pour vous assurer que les binaires Cloud Service Mesh qui s'exécutent dans votre maillage sont exempts de failles connues du public.
    • Workload Identity permet aux charges de travail d'obtenir des identifiants pour appeler les services Google de manière sécurisée.
    • Cloud Key Management Service (Cloud KMS) sécurise les données sensibles ou les identifiants via des modules de sécurité matériels (HSM, Hardware Security Modules). Par exemple, les charges de travail peuvent utiliser Cloud KMS pour stocker des identifiants ou d'autres données sensibles. Le service d'autorité de certification, utilisé pour émettre des certificats pour les charges de travail de réseau maillé, est compatible avec les clés de signature par client et basées sur HSM gérées par Cloud KMS.
    • L'interface réseau de conteneur (CNI) Kubernetes empêche les attaques par élévation de privilèges en éliminant la nécessité d'un conteneur d'initialisation privilégié de Cloud Service Mesh.
  • Sécurité des opérateurs
    • Le contrôle des accès basé sur les rôles Kubernetes (RBAC) limite l'accès aux ressources Kubernetes et les autorisations des opérateurs afin de limiter les attaques provenant d'opérateurs malveillants ou de l'usurpation d'identité.
    • GKE Enterprise Policy Controller valide et audite les configurations des règles dans le maillage pour éviter les erreurs de configuration.
    • L'autorisation binaire Google Cloud garantit que les images de charge de travail du réseau maillé sont celles autorisées par les administrateurs.
    • Google Cloud Audit Logging audite les opérations du réseau maillé.

Le schéma ci-dessous illustre les flux de communication et de configuration avec les solutions de sécurité intégrées à Cloud Service Mesh.

Flux de trafic du schéma de sécurité

Sécurité du cluster

Activer le protocole TLS mutuel strict

Une attaque MITM ("man in the middle") tente d'insérer une entité malveillante entre deux parties qui communiquent afin d'intercepter ou de manipuler la communication. Cloud Service Mesh protège contre les attaques MitM et d'exfiltration de données en appliquant l'authentification et le chiffrement mTLS pour toutes les parties qui communiquent. Le mode permissif utilise le protocole mTLS lorsque les deux côtés le permettent, mais autorise les connexions sans mTLS. En revanche, l'authentification mTLS en mode strict nécessite que le trafic soit chiffré et authentifié avec mTLS et n'autorise pas le trafic en texte brut.

Cloud Service Mesh vous permet de configurer la version TLS minimale des connexions TLS entre vos charges de travail afin de répondre à vos exigences de sécurité et de conformité.

Pour en savoir plus, consultez Cloud Service Mesh, par exemple: mTLS | Appliquer l'authentification mTLS au niveau du réseau maillé.

Activer les contrôles des accès

Les règles de sécurité de Cloud Service Mesh (telles que les règles d'authentification et d'autorisation) doivent être appliquées à tout le trafic entrant et sortant du maillage, sauf s'il existe des justifications solides pour exclure un service ou un pod des règles de sécurité Cloud Service Mesh. Dans certains cas, les utilisateurs peuvent avoir des raisons légitimes de contourner les règles de sécurité de Cloud Service Mesh pour certains ports et plages d'adresses IP. Par exemple, pour établir des connexions natives avec des services non gérés par Cloud Service Mesh. Pour sécuriser Cloud Service Mesh dans de tels cas d'utilisation, consultez la section Gérer de manière sécurisée les exceptions à la règle Cloud Service Mesh.

Le contrôle d'accès aux services est essentiel pour empêcher tout accès non autorisé aux services. L'application mTLS chiffre et authentifie une requête, mais un maillage doit toujours disposer des stratégies d'autorisation Cloud Service Mesh pour appliquer le contrôle des accès aux services. Par exemple, rejeter une requête non autorisée provenant d'un client authentifié.

Les stratégies d'autorisation Cloud Service Mesh offrent un moyen flexible de configurer les contrôles d'accès afin de protéger vos services contre les accès non autorisés. Les règles d'autorisation de Cloud Service Mesh doivent être appliquées en fonction des identités authentifiées dérivées des résultats d'authentification. Les authentifications basées sur mTLS ou JSON Web Token (JWT) doivent être utilisées conjointement dans le cadre des stratégies d'autorisation Cloud Service Mesh.

Appliquer des règles d'authentification Cloud Service Mesh

Jeton Web JSON (JWT)

En plus de l'authentification mTLS, les administrateurs de réseau maillé peuvent demander à un service d'authentifier et d'autoriser les requêtes basées sur JWT. Cloud Service Mesh n'agit pas en tant que fournisseur de jetons JWT, mais authentifie les jetons JWT en fonction des points de terminaison de l'ensemble de clés Web JSON (JWKS) configurés. L'authentification JWT peut être appliquée aux passerelles d'entrée pour le trafic externe ou aux services internes pour le trafic au sein du réseau maillé. L'authentification JWT peut être combinée à l'authentification mTLS lorsqu'un jeton JWT est utilisé en tant qu'identifiant pour représenter l'appelant final, et que le service demandé nécessite de prouver qu'il est appelé pour le compte de l'appelant final. L'application de l'authentification JWT protège contre les attaques qui accèdent à un service sans identifiants valides et pour le compte d'un utilisateur final réel.

Authentification des utilisateurs dans Cloud Service Mesh

L'authentification des utilisateurs Cloud Service Mesh est une solution intégrée pour l'authentification des utilisateurs finaux dans le navigateur et le contrôle des accès à vos charges de travail. Il intègre un maillage de services à des fournisseurs d'identité (IdP) existants pour implémenter un flux de connexion et de consentement OpenID Connect (OIDC) standard basé sur le Web, et utilise des règles d'autorisation Cloud Service Mesh pour le contrôle des accès.

Appliquer des règles d'autorisation

Les règles d'autorisation Cloud Service Mesh contrôlent:

  • Les personnes ou les ressources autorisées à accéder à un service
  • Les ressources qui sont accessibles
  • Les opérations qui peuvent être effectuées sur les ressources autorisées

Les règles d'autorisation sont un moyen polyvalent de configurer le contrôle des accès en fonction des identités réelles exécutées par les services, des propriétés de la couche d'application (couche 7) du trafic (par exemple, des en-têtes de requête) et des propriétés de la couche réseau (couche 3 et couche 4) telles que les plages d'adresses IP et les ports.

Les règles d'autorisation de Cloud Service Mesh doivent être appliquées en fonction des identités authentifiées dérivées des résultats de l'authentification pour empêcher tout accès non autorisé aux services ou aux données.

Par défaut, l'accès à un service doit être refusé, sauf si une règle d'autorisation est explicitement définie pour autoriser l'accès au service. Consultez la section Bonnes pratiques pour les règles d'autorisation pour obtenir des exemples de règles d'autorisation qui refusent les requêtes d'accès.

Les règles d'autorisation doivent limiter autant que possible la confiance. Par exemple, l'accès à un service peut être défini en fonction des chemins d'URL individuels exposés par un service, de sorte que seul un service A puisse accéder au chemin /admin d'un service B.

Les règles d'autorisation peuvent être utilisées avec les règles de réseau Kubernetes, qui ne fonctionnent qu'au niveau de la couche réseau (couche 3 et couche 4), et contrôlent l'accès au réseau pour les adresses IP et les ports sur les pods Kubernetes et les espaces de noms Kubernetes.

Appliquer l'échange de jetons pour accéder aux services de réseau maillé

Pour empêcher les attaques par répétition de jetons qui volent les jetons et les réutilisent pour accéder aux services de réseau maillé, un jeton d'une requête extérieure au réseau maillé doit être échangé contre un jeton interne au réseau maillé de courte durée en périphérie du réseau maillé.

Une requête extérieure au réseau maillé pour accéder à un service de réseau maillé doit inclure un jeton, tel que JWT ou un cookie, afin d'être authentifiée et autorisée par le service de réseau maillé. Un jeton extérieur au réseau maillé peut être de longue durée. Pour empêcher les attaques par répétition de jetons, un jeton extérieur au réseau maillé doit être échangé contre un jeton interne au réseau maillé et de courte durée avec un niveau d'accès limité en périphérie du réseau maillé. Le service de réseau maillé authentifie un jeton interne au réseau maillé et autorise la requête d'accès en fonction du jeton interne au réseau maillé.

Cloud Service Mesh est compatible avec l'intégration à Identity-Aware Proxy (IAP), qui génère un RequestContextToken (jeton interne de maillage de courte durée échangé à partir d'un jeton externe) utilisé dans Cloud Service Mesh pour l'autorisation. Avec l'échange de jetons, les pirates informatiques ne peuvent pas utiliser un jeton volé dans le réseau maillé pour accéder aux services. Le champ d'application et la durée de vie limités du jeton échangé réduisent considérablement le risque d'attaque par répétition de jetons.

Gérer de manière sécurisée les exceptions aux règles Cloud Service Mesh

Vous pouvez avoir des cas d'utilisation particuliers pour votre maillage de services. Par exemple, vous devrez peut-être exposer un certain port réseau au trafic en texte brut. Pour répondre à des scénarios d'utilisation spécifiques, vous devrez parfois créer des exceptions pour autoriser l'exclusion de certains trafics internes ou externes des règles de sécurité Cloud Service Mesh, ce qui entraîne des problèmes de sécurité.

Vous pouvez avoir des raisons légitimes de contourner les règles de sécurité Cloud Service Mesh pour certains ports et plages d'adresses IP. Vous pouvez ajouter des annotations (telles que excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) aux pods pour empêcher le trafic d'être géré par le side-car Envoy. Outre les annotations permettant d'exclure le trafic, vous pouvez contourner le réseau maillé en déployant une application avec l'injection side-car désactivée. Par exemple, en ajoutant une étiquette sidecar.istio.io/inject="false" au pod de l'application.

Le contournement des règles de sécurité Cloud Service Mesh a un impact négatif sur la sécurité globale du système. Par exemple, si le protocole mTLS et les règles d'autorisation de Cloud Service Mesh sont contournés pour un port réseau au moyen d'annotations, il n'y aura aucun contrôle des accès pour le trafic sur le port, et l'écoute clandestine ou la modification du trafic pourront être possibles. De plus, le contournement des règles Cloud Service Mesh affecte également les règles hors sécurité, telles que les règles de réseau.

Lorsque la règle de sécurité Cloud Service Mesh est contournée pour un port ou une adresse IP (intentionnellement ou non), d'autres mesures de sécurité doivent être mises en place pour sécuriser le maillage, et surveiller les exceptions de sécurité, les failles de sécurité potentielles et l'état général des mesures de sécurité. Pour sécuriser votre réseau maillé dans ces scénarios, vous pouvez procéder comme suit :

  • Assurez-vous que le trafic contournant les side-cars est chiffré de manière native et authentifié pour empêcher les attaques MITM.
  • Appliquez les règles de réseau Kubernetes pour limiter la connectivité des ports avec des exceptions de règle (par exemple, limiter un port avec des exceptions à la règle afin d'autoriser uniquement le trafic provenant d'un autre service dans le même espace de noms) ou pour n'autoriser que le trafic à passer par les ports auxquels la stratégie de sécurité Cloud Service Mesh est appliquée.
  • Appliquez GKE Enterprise Policy Controller pour valider automatiquement les règles Cloud Service Mesh. Par exemple, assurez-vous que les side-cars Cloud Service Mesh sont toujours injectés aux charges de travail.

Appliquer les règles de réseau Kubernetes

Cloud Service Mesh s'appuie sur la plate-forme sous-jacente (par exemple, Kubernetes). Ainsi, la sécurité de Cloud Service Mesh dépend de la sécurité de la plate-forme sous-jacente. Par exemple, sans le contrôle des utilisateurs autorisés à mettre à jour les ressources Kubernetes, un utilisateur peut modifier le déploiement Kubernetes d'un service pour contourner le side-car du service.

Pour établir une stratégie de sécurité renforcée pour un maillage de services, les mécanismes de sécurité de la plate-forme sous-jacente doivent être appliqués de manière à fonctionner conjointement avec les règles de sécurité de Cloud Service Mesh.

Les règles de réseau Kubernetes s'appliquent au niveau de la couche réseau (L3 et L4) pour les adresses IP et les ports sur les pods et les espaces de noms Kubernetes. Les règles de réseau Kubernetes peuvent être appliquées conjointement aux règles Cloud Service Mesh pour améliorer la sécurité du maillage.

Par exemple, l'administrateur du maillage peut configurer les règles de réseau Kubernetes pour n'autoriser que le trafic à utiliser les ports pour lesquels la stratégie de sécurité Cloud Service Mesh est appliquée. Si l'ensemble du trafic doit être appliqué avec l'authentification mTLS de Cloud Service Mesh, l'administrateur peut configurer une règle de réseau Kubernetes pour n'autoriser que le trafic sur les ports configurés avec la règle mTLS de Cloud Service Mesh. L'administrateur du réseau maillé peut également configurer des règles de réseau Kubernetes pour limiter la connectivité des ports avec des exceptions à ces règles. Par exemple, limitez la connectivité de ces ports à un espace de noms.

Sécuriser l'accès au plan de contrôle

Le plan de contrôle Cloud Service Mesh authentifie tous les clients qui se connectent. Ainsi, seuls les appelants disposant d'identifiants valides (certificats Kubernetes JWT ou X.509 émis par des autorités de certification autorisées) peuvent accéder au plan de contrôle de Cloud Service Mesh. TLS chiffre les connexions entre les charges de travail et le plan de contrôle Cloud Service Mesh.

En plus du mécanisme d'authentification, pour Cloud Service Mesh dans le cluster, des règles de réseau Kubernetes peuvent être déployées pour isoler l'espace de noms système Cloud Service Mesh (par défaut, istio-system) des espaces de noms non gérés et des clients en dehors du maillage, tout en permettant aux plans de données d'accéder au plan de contrôle. Les règles de pare-feu VPC peuvent empêcher le trafic en dehors d'un cluster d'atteindre Istiod. Avec ces mesures d'isolation du réseau, un pirate informatique à l'extérieur du réseau maillé ne pourra pas accéder au plan de contrôle, même s'il possède des identifiants valides. Pour les plans de contrôle gérés, Google gère la sécurité des plans de contrôle, et ces règles d'isolation du réseau pour les plans de contrôle ne sont pas nécessaires.

Appliquer des limites d'espace de noms

Pour empêcher un utilisateur d'un espace de noms d'accéder aux ressources d'un espace de noms non autorisé ou de les mettre à jour, procédez comme suit :

  • Appliquez des contrôles des accès.
  • Appliquez les règles de réseau Kubernetes. Si les services d'un espace de noms ne comportent pas de trafic en dehors de cet espace de noms, l'administrateur du réseau maillé doit déployer une règle de réseau Kubernetes qui n'autorise le trafic qu'à l'intérieur de l'espace de noms : aucune entrée ni sortie de l'espace de noms.
  • Appliquez les règles Kubernetes RBAC.
    • Les rôles des administrateurs d'application doivent être liés à un espace de noms.
    • Autorisez uniquement les administrateurs de réseau maillé à disposer du rôle ClusterRole.

Appliquer les règles Kubernetes RBAC

Les administrateurs du maillage doivent appliquer des stratégies Kubernetes RBAC pour contrôler qui est autorisé à accéder aux ressources Kubernetes et à les mettre à jour. Le contrôle des accès Kubernetes peut limiter les risques de sécurité au sein du réseau maillé. Par exemple, les utilisateurs non autorisés ne doivent pas être autorisés à modifier les déploiements Kubernetes et à contourner les mesures d'application de la règle Cloud Service Mesh. Les rôles d'un utilisateur doivent être liés à un espace de noms de sorte que cet utilisateur ne soit pas autorisé à accéder à plus d'espaces de noms qu'il n'en a besoin. Pour obtenir des guides détaillés et des exemples de configuration de RBAC, consultez la page Configurer le contrôle des accès basé sur les rôles. Après avoir activé Workload Identity, vous pouvez également autoriser un compte de service Kubernetes à agir en tant que compte de service IAM.

Sécurité en périphérie du réseau maillé

Comme la plupart des attaques peuvent également provenir de l'extérieur d'un cluster, il est essentiel de garantir la sécurité à la périphérie du réseau maillé.

Contrôle des accès à l'entrée du cluster

Cloud Service Mesh reçoit le trafic externe entrant via la passerelle d'entrée. Les services exposés par la passerelle d'entrée sont susceptibles de rencontrer des attaques provenant de sources externes. Les administrateurs de sécurité doivent toujours s'assurer que les services exposés au trafic externe via les passerelles d'entrée sont suffisamment sécurisés pour se protéger contre les attaques.

Ingress doit appliquer l'authentification et l'autorisation pour les services exposés aux appelants externes.

  • Appliquez des règles de sécurité d'entrée au cluster. Lorsque le cluster doit recevoir du trafic externe, l'administrateur du maillage doit appliquer des règles de sécurité d'entrée, y compris des règles TLS de passerelle, d'authentification et d'autorisation de Cloud Service Mesh, afin d'authentifier les requêtes externes et de vérifier qu'elles sont autorisées à accéder aux services exposés par la passerelle d'entrée. L'application de règles de sécurité d'entrée protège contre les attaques provenant de l'extérieur du réseau maillé qui tentent d'accéder à un service sans identifiants ni autorisations valides.
  • Utilisez Cloud Armor comme service de pare-feu d'application Web (WAF) pour vous protéger contre les attaques Web (par exemple, les attaques par injection et les exécutions à distance). Pour en savoir plus, consultez la page De la périphérie au réseau : Exposer les applications de maillage de services via GKE Ingress.

Réguler le trafic de sortie du cluster

La sécurité de sortie du cluster est essentielle pour la sécurité du réseau maillé, car les règles de sécurité de sortie peuvent vous protéger contre les attaques par exfiltration de données, appliquer un filtrage du trafic de sortie et appliquer l'initiation TLS pour le trafic de sortie. Les administrateurs de sécurité doivent réguler et auditer le trafic de sortie du cluster.

Outre l'utilisation de pare-feu VPC pour restreindre le trafic de sortie, les administrateurs de réseau maillé doivent également appliquer des règles de sécurité de sortie pour le cluster et configurer son trafic sortant pour passer par les passerelles de sortie.

Les règles de sortie peuvent atténuer les attaques suivantes :

  • Les attaques par exfiltration de données
  • Les pods de service peuvent être exploités par des pirates informatiques si leurs failles CVE ne sont pas corrigées. Les pods compromis peuvent devenir un botnet contrôlé par des pirates informatiques afin d'envoyer du spam ou de lancer des attaques DoS.

Les règles d'autorisation appliquées aux passerelles de sortie peuvent garantir que seuls les services autorisés sont autorisés à envoyer du trafic vers des hôtes particuliers en dehors du réseau maillé. Dans le même temps, pour le trafic quittant le réseau maillé, au lieu de gérer l'initiation TLS sur les side-cars individuels, le protocole TLS peut être initié sur les passerelles de sortie. Cela permet d'initier un trafic TLS uniforme et plus sécurisé, car les certificats clients pour mTLS peuvent être isolés des espaces de noms où les applications s'exécutent.

Utiliser un cluster privé ou VPC Service Controls pour verrouiller les accès externes

En plus d'appliquer des règles de sécurité aux entrées et aux sorties, verrouillez l'accès externe à l'aide d'un cluster privé ou de VPC Service Controls lorsque cela est possible. Alors que les règles de sécurité sont contrôlées par les administrateurs de sécurité du réseau maillé, la configuration du cluster privé ou VPC Service Controls peut être appliqué par les administrateurs de sécurité de l'organisation.

VPC Service Controls peut être appliqué pour définir un périmètre de sécurité pour les services pour :

  • Empêcher les services d'accéder aux ressources externes.
  • Empêcher les utilisateurs externes d'accéder aux services d'un périmètre de sécurité.

VPC Service Controls permet de vous protéger contre les attaques par exfiltration de données et d'empêcher les pirates externes d'accéder aux services au sein d'un réseau maillé.

Se protéger contre les attaques DDoS externes

Les attaques DDoS externes peuvent surcharger les passerelles d'entrée et les services de backend, empêchant ainsi le traitement des requêtes légitimes. Cloud Armor peut être utilisé pour vous protéger contre les attaques DDoS. Cloud Armor protège contre non seulement les couches réseau (L3 et L4), mais également les couches d'application (L7), des attaques DDoS.

Sécurité pour l'administration et l'automatisation du réseau maillé

Il est important de prendre en compte la sécurité pour les opérations administratives et toute automatisation que vous créez autour de votre réseau maillé, par exemple l'intégration et la livraison continues. Les pratiques suivantes visent à garantir que le réseau maillé peut être exploité en toute sécurité, sans exposer les services à des attaques supplémentaires.

Segmenter les rôles utilisés pour les opérations de réseau maillé

En suivant le même principe que le contrôle des accès basé sur les rôles, les utilisateurs d'un réseau maillé doivent être classés en fonction de leurs rôles. Chaque rôle ne doit disposer que de l'ensemble minimal de droits requis par le rôle.

Par exemple, l'ensemble des utilisateurs qui effectuent des déploiements de services ne doit pas disposer de droits permettant de mettre à jour les règles d'authentification et d'autorisation.

Il existe différentes catégories d'opérateurs. Par exemple, les opérateurs de cluster et les opérateurs d'espace de noms. Il est important d'éviter l'élévation des privilèges d'un opérateur, ce qui pourrait entraîner un accès non permis à des ressources non autorisées.

Les règles Kubernetes RBAC permettent aux administrateurs de réseau maillé de limiter l'accès aux ressources uniquement aux utilisateurs autorisés.

Valider automatiquement les configurations des règles

Les opérateurs peuvent mal configurer accidentellement les règles Cloud Service Mesh, ce qui peut entraîner des incidents de sécurité graves. Pour éviter les erreurs de configuration et valider automatiquement les règles Cloud Service Mesh, les administrateurs de maillage peuvent utiliser Policy Controller pour appliquer des contraintes aux configurations des règles.

Pour éviter de faire trop confiance aux personnes autorisées à mettre à jour les règles de sécurité Cloud Service Mesh et à automatiser la validation des règles Cloud Service Mesh, les administrateurs du maillage doivent implémenter des contraintes sur les règles Cloud Service Mesh à l'aide de Policy Controller.

Policy Controller est basé sur le projet Open Source Gatekeeper et peut être exécuté en tant que contrôleur d'admission Kubernetes pour refuser que des ressources non valides soient appliquées ou en mode audit afin que les administrateurs puissent être avertis en cas de non-respect des règles. Policy Controller peut valider automatiquement le déploiement des ressources dans le maillage, par exemple en vérifiant que les annotations sur un déploiement ne contournent pas les règles Cloud Service Mesh, en s'assurant que les règles Cloud Service Mesh sont conformes aux attentes et en vérifiant qu'un déploiement n'inclut pas de fonctionnalités racine (telles que NET_ADMIN et NET_RAW).

Policy Controller peut également auditer les ressources Cloud Service Mesh existantes par rapport aux contraintes afin de détecter les erreurs de configuration des règles.

Voici quelques exemples de règles de sécurité appliquées par GKE Enterprise Policy Controller:

La bibliothèque de modèles de contraintes fournie avec Policy Controller contient un ensemble de modèles de contraintes qui peuvent être utilisés avec le groupe de contraintes de sécurité Cloud Service Mesh prêt à l'emploi pour appliquer des bonnes pratiques de sécurité spécifiques à Cloud Service Mesh, par exemple, des règles d'authentification, d'autorisation et de trafic. Voici quelques exemples de contraintes incluses dans le lot :

  • Appliquez l'authentification mTLS stricte au niveau du réseau maillé PeerAuthentication.
  • Appliquer l'ensemble des PeerAuthentications ne peut pas écraser le mode mTLS strict
  • Appliquez l'autorisation AuthorizationPolicy default deny au niveau du réseau maillé.
  • Appliquer les modèles sécurisés de la règle AuthorizationPolicy
  • Appliquer les side-cars Cloud Service Mesh sont toujours injectés aux charges de travail.

Pour gérer les exceptions et les situations de type "bris de glace", l'administrateur de réseau maillé peut :

Utiliser une approche GitOps avec Config Sync pour éviter les écarts de configuration

Les écarts de configuration se produisent lorsque la configuration des règles d'un réseau maillé diffère de la source de vérité. Config Sync peut être utilisé pour éviter les écarts de configuration.

Appliquer la journalisation et la surveillance d'audit

Les administrateurs du réseau maillé doivent surveiller les éléments suivants :

Ces ressources d'observabilité peuvent être utilisées pour vérifier que la configuration de la sécurité fonctionne comme prévu et surveiller les exceptions à l'application des règles de sécurité. Par exemple, un accès qui n'est pas passé par des side-cars, qui n'avait pas d'identifiants valides, mais qui a atteint un service.

Bien qu'un logiciel d'observabilité Open Source (par exemple, Prometheus) puisse être utilisé avec Cloud Service Mesh, nous vous recommandons vivement d'utiliser Google Cloud Observability (anciennement Stackdriver). La solution d'observabilité intégrée pour Google Cloud fournit une journalisation, une collecte de métriques, une surveillance et des alertes qui sont entièrement gérées et faciles à utiliser.

Protéger l'autorité de certification pour les certificats dans le cluster

Par défaut, Cloud Service Mesh utilise une autorité de certification gérée par Google, appelée "autorité de certification Cloud Service Mesh".

Si vous utilisez l'autorité de certification Istio non gérée, qui est hébergée dans Istiod, la clé de signature de l'autorité de certification est stockée dans un secret Kubernetes et accessible aux opérateurs qui ont accès à la ressource de secret dans l'espace de noms istio-system. Cela présente un risque, car un opérateur peut être en mesure d'utiliser la clé de l'autorité de certification indépendamment de l'autorité de certification d'Istio, et potentiellement de signer des certificats de charge de travail de manière indépendante. Il existe également un risque qu'une clé de signature d'autorité de certification autogérée puisse être divulguée par accident en raison d'une erreur opérationnelle.

Pour protéger la clé de signature de l'autorité de certification, l'administrateur du maillage peut mettre à niveau le maillage pour qu'il utilise l'autorité de certification Cloud Service Mesh ou Certificate Authority Service (CA Service), qui sont sécurisés et gérés par Google. Par rapport à l'autorité de certification de Cloud Service Mesh, CA Service prend en charge par client les clés de signature via Cloud KMS reposant sur Cloud HSM. CA Service accepte également les charges de travail réglementées, contrairement à l'autorité de certification de Cloud Service Mesh.

Sécurité des charges de travail

La sécurité des charges de travail vous protège contre les attaques qui compromettent les pods de charge de travail, puis utilisent les pods compromis pour lancer des attaques sur le cluster (par exemple les attaques de botnet).

Limiter les privilèges des pods

Un pod Kubernetes peut disposer de privilèges qui affectent d'autres pods sur le nœud ou le cluster. Il est important d'appliquer des restrictions de sécurité aux pods de charge de travail pour empêcher un pod compromis de lancer des attaques sur le cluster.

Pour appliquer le principe du moindre privilège aux charges de travail sur un pod :

  • Les services déployés dans un réseau maillé doivent s'exécuter avec le moins de privilèges possible.
  • Les pods Kubernetes s'exécutant en mode privilégié peuvent manipuler les piles réseau et d'autres fonctionnalités de noyau sur l'hôte. GKE Enterprise Policy Controller peut être utilisé pour empêcher les pods d'exécuter des conteneurs privilégiés.
  • Cloud Service Mesh peut être configuré pour utiliser un conteneur init afin de configurer la redirection du trafic iptables vers le side-car. Pour ce faire, l'utilisateur effectuant des déploiements de charges de travail doit disposer de privilèges permettant de déployer des conteneurs avec les fonctionnalités "NET_ADMIN" et "NET_RAW". Pour éviter le risque d'exécuter des conteneurs avec des droits élevés, les administrateurs de maillage peuvent enable le plug-in CNI Istio pour configurer la redirection du trafic vers les side-cars.

Sécuriser les images de conteneurs

Les pirates informatiques peuvent lancer des attaques en exploitant des images de conteneur vulnérables. Les administrateurs doivent appliquer l'autorisation binaire pour vérifier l'intégrité des images de conteneur et s'assurer que seules les images de conteneur fiables sont déployées dans le réseau maillé.

Atténuer les failles du réseau maillé

  • Container Analysis. Container Analysis permet d'analyser et de détecter les failles sur les charges de travail GKE.
  • Gestion des CVE (Common Vulnerabilities and Exposures, ou failles et expositions courantes) Une fois une faille détectée dans une image de conteneur, les administrateurs du réseau maillé doivent la corriger dès que possible. Pour le Cloud Service Mesh géré avec un plan de données géré, Google gère automatiquement la correction des failles CVE qui affectent les images du maillage.

Accéder aux services Google en toute sécurité à l'aide de Workload Identity

Workload Identity est la méthode recommandée pour que les charges de travail du réseau maillé puissent accéder en toute sécurité aux services Google. Sinon, stocker une clé de compte de service dans un secret Kubernetes et utiliser la clé de compte de service pour accéder aux services Google n'est pas une alternative aussi sécurisée en raison des risques de fuite d'identifiants, élévation des privilèges, divulgation d'informations et non-répudiation.

Surveiller l'état de la sécurité via le tableau de bord de sécurité et la télémétrie

Un maillage de services peut présenter des exceptions de sécurité et des failles potentielles. Il est essentiel de détecter et de surveiller l'état de sécurité d'un réseau maillé, y compris les règles de sécurité appliquées, les exceptions de sécurité et les failles de sécurité potentielles dans le réseau maillé. Le tableau de bord de sécurité GKE Enterprise et la télémétrie peuvent être utilisés pour afficher et surveiller l'état de sécurité du maillage.

La télémétrie surveille l'état et les performances des services d'un réseau maillé, ce qui permet aux administrateurs du réseau maillé d'observer les comportements des services (tels que les SLO, le trafic anormal, l'interruption de service, la topologie).

Le tableau de bord de sécurité GKE Enterprise analyse et visualise les stratégies de sécurité appliquées à une charge de travail dans un maillage de services, y compris les stratégies de contrôle des accès (stratégies réseau Kubernetes, stratégies d'autorisation binaire et stratégies de contrôle d'accès aux services) et les stratégies d'authentification (mTLS).

Sécurité des données utilisateur et des identifiants sensibles

Les données utilisateur ou identifiants sensibles peuvent être vulnérables aux attaques provenant de pods ou d'opérations malveillantes si elles sont stockées dans l'espace de stockage persistant du cluster, par exemple en utilisant des secrets Kubernetes ou directement dans des pods. Elles sont également vulnérables aux attaques réseau si elles sont transférées sur le réseau pour l'authentification auprès des services.

  • Si possible, stockez les données utilisateur et les identifiants sensibles dans un espace de stockage protégé, tel que Secret Manager et Cloud KMS.
  • Désignez des espaces de noms distincts pour les pods Kubernetes qui accèdent à des données sensibles, et définissez des règles Kubernetes pour les rendre inaccessibles depuis d'autres espaces de noms. Segmentez les rôles utilisés pour les opérations et appliquez des limites d'espace de noms.
  • Appliquez l'échange de jetons pour empêcher l'exfiltration de jetons de longue durée à privilèges élevés.

Étapes suivantes