Cloud Service Mesh avec les bonnes pratiques de sécurité pour les API Istio

Ce document décrit les bonnes pratiques pour établir et régir une configuration Cloud Service Mesh sécurisée exécutée sur Google Kubernetes Engine (GKE). Les consignes fournies dans le au-delà des paramètres utilisés pour configurer et provisionner Cloud Service Mesh et explique comment utiliser Cloud Service Mesh avec d'autres produits Google Cloud des produits et des fonctionnalités pour vous protéger contre les menaces de sécurité que les applications dans un réseau maillé.

L'audience visée pour ce document inclut les administrateurs qui gèrent des règles dans un Cloud Service Mesh et les propriétaires de services qui exécutent des services dans un 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 :

Présentation

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 du comportement du réseau, ce qui permet de dissocier le travail des équipes responsables pour livrer et publier des fonctionnalités d'application qui relèvent de la responsabilité administrateurs responsables de la sécurité et de la mise en réseau.

Cloud Service Mesh est basé sur le maillage de services Open Source Istio, qui permet des configurations et des topologies sophistiquées. Selon la structure de votre organisation, une ou plusieurs équipes ou rôles peuvent être responsables de l'installation et la configuration d'un réseau maillé. Le maillage de services Cloud par défaut sont choisis pour protéger les applications, mais dans certains cas, vous devrez peut-être des configurations personnalisées, ou vous devrez peut-être accorder des exceptions en excluant certains des applications, des ports ou des adresses IP à un réseau maillé. Avoir des contrôles dans pour gérer les configurations de réseau maillé et les exceptions de sécurité.

Ce document complète la documentation sur les bonnes pratiques de sécurité d'Istio, qui comprend des recommandations de configuration détaillées pour le protocole TLS mutuel (mTLS), les règles d'autorisation, les passerelles et d'autres configurations de sécurité. Considérez ces recommandations comme une base à utiliser avec les bonnes pratiques décrites dans ce document. Ce document décrit d'autres bonnes pratiques et comment les technologies de Google Cloud peuvent sécuriser l'ensemble des couches, composants et flux d'informations d'un maillage.

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 part du principe que les menaces de sécurité proviennent périmètre de sécurité de votre entreprise. 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 pourraient essayer d'obtenir des privilèges élevés pour mener des opérations malveillantes dans un maillage, telles que la modification de ses stratégies 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é de Cloud Service Mesh afin d'exclure certains trafics (internes ou externes). Pour sécuriser gérer de tels cas, consultez Gérer de manière sécurisée les exceptions aux règles dans ce document.
  • 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é. Erreurs de configuration ou configurations non sécurisées du réseau maillé et le trafic ou les opérations anormales du réseau maillé ne sont pas transmis au l'attention des 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. Le haut niveau l'objectif de la stratégie de sécurité proposée pour Cloud Service Mesh est de sécuriser un service en intégrant plusieurs mécanismes de sécurité à différentes couches, ce qui assurer conjointement 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 offre une sécurité sur plusieurs couches, y compris :

  • Sécurité en périphérie du réseau maillé
    • La sécurité au niveau de l'entrée de Cloud Service Mesh fournit un contrôle des accès pour le trafic externe et sécurise l'accès externe aux API exposées par les services du réseau maillé.
    • La sécurité au niveau de la sortie de Cloud Service Mesh régule le trafic sortant des charges de travail internes.
    • L'authentification des utilisateurs de 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.
    • Gestion des certificats de passerelle Cloud Service Mesh protège et alterne les clés privées et les certificats X.509 utilisés par Passerelles d'entrée et de sortie Cloud Service Mesh utilisant Certificate Authority Service.
    • 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 trafic entre charges de travail le chiffrement et l'authentification.
    • L'autorité de certification Cloud Service Mesh 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 un contrôle d'accès aux services du réseau maillé en fonction de leur identité et d'autres attributs.
    • Le tableau de bord de sécurité GKE Enterprise fournit une surveillance des configurations des règles de sécurité et des règles de réseau Kubernetes pour les charges de travail.
    • Contrôle d'accès aux pods appliqué par les règles de réseau Kubernetes en fonction des adresses IP, des étiquettes de pods, des espaces de noms, etc.
  • Sécurité des charges de travail
    • Tenez-vous informé des versions de sécurité de Cloud Service Mesh pour vous assurer que les binaires de Cloud Service Mesh exécutés dans votre réseau maillé sont exempts de failles publiques.
    • Fédération d'identité de charge de travail pour GKE permet aux charges de travail d'obtenir des identifiants pour appeler en toute sécurité les services Google.
    • Cloud Key Management Service (Cloud KMS) Sécurisation des données sensibles ou des identifiants à l'aide de modules matériels de sécurité (HSM). 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 CNI (Container Network Interface) de Kubernetes empêche les attaques par élévation de privilèges, sans qu’il soit nécessaire Conteneur d'initialisation 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 de règles au sein du réseau maillé afin d'é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.
    • Cloud Audit Logs audite les opérations du réseau maillé.

Le schéma suivant illustre les flux de communication et de configuration avec les solutions de sécurité intégrées dans Cloud Service Mesh.

Flux de trafic de sécurité

Sécurité du cluster

Cette section décrit les bonnes pratiques liées à la sécurité du cluster.

Activer le protocole TLS mutuel strict

Une attaque de type « man-in-the-middle » (MitM) tente d’insérer une entité malveillante entre deux communiquer des parties pour espionner ou manipuler la communication. Cloud Service Mesh protège contre les attaques MitM et d'exfiltration de données en appliquant Authentification et 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 pour les 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

Nous vous recommandons d'appliquer les règles de sécurité Cloud Service Mesh (telles que les règles d'authentification et d'autorisation) à tout le trafic entrant et sortant du réseau maillé, à moins qu'il n'existe de 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 Règles de sécurité Cloud Service Mesh pour certains ports et adresses IP plages d'adresses IP, par exemple, pour établir des connexions natives avec des services et non gérées par Cloud Service Mesh. Pour sécuriser Cloud Service Mesh avec de tels cas d'utilisation, consultez Gérez de manière sécurisée les exceptions à la règle Cloud Service Mesh.

Le contrôle des 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 réseau maillé nécessite toujours des règles d'autorisation Cloud Service Mesh pour appliquer le contrôle des accès aux services (par exemple, en rejetant une requête non autorisée provenant d'un client authentifié).

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

Appliquer les règles d'authentification Cloud Service Mesh

Lorsque vous réfléchissez aux règles d'authentification Cloud Service Mesh, tenez compte des points suivants.

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 du configurés de points de terminaison JWKS (ensemble de clés Web JSON). 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 avec Cloud Service Mesh

Authentification des utilisateurs dans Cloud Service Mesh est une solution intégrée pour l'authentification et l'accès des utilisateurs finaux à vos charges de travail. Il intègre un maillage de services à une solution Fournisseurs (IdP) pour implémenter une connexion Web OpenID Connect (OIDC) standard et le flux de consentement, et utilise l'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 stratégies d'autorisation offrent un moyen polyvalent de configurer le contrôle des accès les identités réelles que les services exécutent en tant que couche d’application (couche 7) du trafic (par exemple, les en-têtes de requête) et la couche réseau (couche 3) et de couche 4) comme les plages d'adresses IP et les ports.

Nous recommandons d'appliquer les règles d'autorisation Cloud Service Mesh basée sur des identités authentifiées dérivées des résultats d'authentification contre les accès non autorisés aux services ou aux données.

Par défaut, l'accès à un service est refusé à moins qu'une règle d'autorisation est explicitement défini 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 stratégies d'autorisation sont destinées à restreindre 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 le service A puisse accéder au chemin /admin du service B.

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

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é, assurez-vous qu'un jeton d'une requête extérieure au réseau maillé est é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 maillé doit inclure un (un jeton JWT ou un cookie, par exemple) doit être authentifié et autorisé par Google Cloud. Un jeton provenant de l'extérieur du maillage peut avoir une longue durée de vie. Pour empêcher les attaques par répétition de jetons, échangez un jeton extérieur au réseau maillé 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 intégration à Identity-Aware Proxy (IAP), qui génère un RequestContextToken (un jeton interne au 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. La portée et la durée de vie limitées du jeton échangé réduisent considérablement le risque d'une attaque par rejeu de jeton.

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 peut-être parfois créer des exceptions permettant d'exclure certains trafics internes ou externes des règles de sécurité Cloud Service Mesh, ce qui pose des problèmes de sécurité.

Vous avez peut-être 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 annotations tels que excludeInboundPorts, excludeOutboundPorts et excludeOutboundIPRanges aux pods pour empêcher que le trafic soit géré par 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 les règles d'autorisation et mTLS de Cloud Service Mesh sont ignorées pour un port réseau au moyen d'annotations, il n'y aura pas de contrôle d'accès pour le trafic sur le port, et l'écoute clandestine ou la modification du trafic pourraient être possibles. En outre, le contournement des règles Cloud Service Mesh affecte également les règles non liées à la sécurité, telles que les règles de réseau.

Lorsque la stratégie de sécurité Cloud Service Mesh est contournée pour un port ou l'adresse IP (soit délibérément ou non, nous vous recommandons vivement de placer d'autres des mesures de sécurité pour sécuriser le réseau maillé et surveiller les exceptions de sécurité, les failles de sécurité potentielles et l'état général de l'application 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 qui contourne les side-cars est chiffré de manière native et authentifiés pour empêcher les attaques MitM.
  • Appliquer des règles de réseau Kubernetes pour limiter la connectivité des ports avec des exceptions de règles (par exemple, limiter un port avec des exceptions de règles pour n'autoriser que 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 pour lesquels la règle de sécurité Cloud Service Mesh est appliquée.

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é. Vous pouvez utiliser Config Sync pour éviter les écarts de configuration.

Appliquer Cloud Audit Logs et surveiller

Nous recommandons aux administrateurs de réseau maillé de surveiller les éléments suivants:

Les administrateurs peuvent utiliser ces ressources d'observabilité pour vérifier que la sécurité fonctionne comme prévu et de surveiller les exceptions à la sécurité l'application des règles. 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 que les logiciels d'observabilité Open Source (par exemple, Prometheus) peut avec Cloud Service Mesh, nous vous recommandons vivement d'utiliser Observabilité Google Cloud. Cette solution d'observabilité intégrée pour Google Cloud propose des fonctionnalités la collecte de métriques, la surveillance et les alertes, qui sont entièrement gérées.

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 droits qui ont un impact sur d'autres pods du nœud ou sur 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.
  • Vous pouvez configurer Cloud Service Mesh pour utiliser un conteneur init configurer la redirection du trafic iptables vers le side-car. Pour ce faire, l'utilisateur doit créer des déploiements de charges de travail disposant de privilèges permettant de déployer des conteneurs avec les fonctionnalités NET_ADMIN et NET_RAW. Pour éviter les risques liés à l'exécution de conteneurs avec des privilèges élevés, les administrateurs de réseau maillé peuvent activer 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 conteneurs 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é

  • Artifact Analysis peut analyser et détecter les failles des 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é peuvent la corriger dès que possible. Google gère automatiquement l'application des correctifs CVE qui affectent les images du maillage.

Utiliser la fédération d'identité de charge de travail pour GKE pour accéder de façon sécurisée aux services Google

Fédération d'identité de charge de travail pour GKE est la solution recommandée pour que les charges de travail maillées puissent accéder de façon sécurisée aux services Google. L'alternative au stockage clé de compte de service dans un secret Kubernetes et à l'aide de la clé de compte de service pour accéder ne sont pas aussi sécurisés en raison des risques fuite d'identifiants, élévation des privilèges, divulgation d'informations la 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 comporter 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é. Vous pouvez utiliser le tableau de bord de sécurité de GKE Enterprise et la télémétrie pour afficher et surveiller l'état de sécurité du réseau maillé.

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é de GKE Enterprise affiche les règles de sécurité appliquées à une charge de travail dans un service mesh, y compris les règles de contrôle d'accès (règles de réseau Kubernetes, règles d'autorisation binaire et règles de contrôle d'accès au service) et les règles d'authentification (mTLS).

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

Si vous stockez des données utilisateur sensibles ou des identifiants dans le cluster persistant (secrets Kubernetes ou directement dans les pods, par exemple), les données ou identifiants peuvent être vulnérables aux attaques provenant de pods ou à des opérations malveillantes. Les données 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.