Cette page a été traduite par l'API Cloud Translation.

À propos de l'autorité du plan de contrôle GKE

Autopilot Standard

Cette page décrit les options proposées par Google Kubernetes Engine (GKE) pour améliorer votre visibilité et votre contrôle sur la sécurité du plan de contrôle géré. Ces options sont collectivement appelées autorité du plan de contrôle GKE. Cette page est destinée aux responsables de la sécurité des informations, aux administrateurs de la conformité et aux analystes qui souhaitent répondre aux besoins stricts en matière de confidentialité et de sécurité pour le traitement des données sensibles.

À propos des fonctionnalités d'autorité du plan de contrôle GKE

Dans GKE, Google Cloud gère entièrement la configuration de sécurité du plan de contrôle, y compris le chiffrement du stockage au repos, et configure les clés et les autorités de certification (CA) qui signent et valident les identifiants dans vos clusters. Les nœuds du plan de contrôle pour les clusters GKE existent dans les projets gérés par Google Cloud . Pour en savoir plus sur le rôle de Google Cloud , consultez Responsabilité partagée de GKE.

L'autorité du plan de contrôle GKE est un ensemble facultatif de fonctionnalités de visibilité et de contrôle qui vous permettent de vérifier et de gérer des aspects spécifiques de ces nœuds de plan de contrôle entièrement gérés. Ces fonctionnalités sont idéales si vous avez des exigences telles que les suivantes :

Vous travaillez dans un secteur hautement réglementé, comme la finance, la santé ou l'administration, avec des exigences de conformité spécifiques.
Vous traitez des données sensibles qui sont soumises à des exigences strictes en matière de sécurité et de chiffrement.
Vous souhaitez améliorer la visibilité sur GKE pour gagner en confiance lorsque vous exécutez des charges de travail critiques.
Vous devez respecter des exigences spécifiques en matière de conformité ou d'audit concernant le chiffrement des données, l'intégrité des logiciels ou la journalisation.
Vous disposez de charges de travail très sensibles qui traitent des données critiques, et vous souhaitez avoir de la visibilité sur le chiffrement de ces données et l'accès à celles-ci.
Vous souhaitez appliquer des règles de sécurité personnalisées qui répondent à des exigences organisationnelles ou réglementaires spécifiques.
Vous souhaitez bénéficier d'un niveau de transparence et de visibilité amélioré dans vos environnements GKE, en particulier en ce qui concerne les actions effectuées parGoogle Cloud dans le plan de contrôle.

Avantages de l'autorité du plan de contrôle GKE

Les fonctionnalités de l'autorité du plan de contrôle GKE sont idéales dans les environnements très réglementés qui appliquent des règles de sécurité ou d'audit strictes. L'utilisation de ces fonctionnalités offre les avantages suivants :

Visibilité et contrôle améliorés : profitez de fonctionnalités supplémentaires de visibilité, de contrôle et de chiffrement pour votre plan de contrôle GKE.
Conformité simplifiée : respectez les exigences réglementaires et sectorielles grâce à des journaux d'audit précis et des règles de sécurité personnalisables.
Confiance et transparence accrues : obtenez des insights sur les actions effectuées parGoogle Cloud dans le plan de contrôle lors de la résolution des demandes d'assistance client.
Atténuation des risques : détectez les menaces potentielles pour le plan de contrôle géré et réagissez-y de manière proactive grâce à des journaux complets.
Gestion standardisée des autorités de certification et des clés : gérez les autorités de certification de votre cluster GKE à l'aide de Certificate Authority Service. Vous pouvez ainsi déléguer la gestion des certificats à des équipes spécifiques et appliquer de manière exhaustive les règles relatives aux autorités de certification. De plus, gérez vos clés de chiffrement de disque du plan de contrôle à l'aide de Cloud KMS pour une délégation de gestion similaire.

Disponibilité de l'autorité du plan de contrôle GKE

Les régions et les zones dans lesquelles vous pouvez utiliser l'autorité du plan de contrôle GKE dépendent de votre souhait d'utiliser ou non des fonctionnalités spécifiques :

Pour chiffrer les disques de démarrage de votre plan de contrôle avec une clé de chiffrement gérée par le client, votre cluster doit se trouver dans l'une des régions suivantes :
- asia-east1
- asia-northeast1
- asia-southeast1
- europe-west1
- europe-west4
- us-central1
- us-east1
- us-east4
- us-east5
- us-south1
- us-west1
- us-west3
- us-west4
Pour utiliser les nœuds Confidential GKE avec l'autorité du plan de contrôle GKE, votre cluster doit se trouver dans une région compatible avec le mode Confidentiel pour Hyperdisk équilibré.

Si vous n'utilisez pas ces fonctionnalités, vous pouvez utiliser l'autorité du plan de contrôle GKE dans n'importe quel emplacement Google Cloud .

Fonctionnement de l'autorité du plan de contrôle GKE

Les fonctionnalités que vous pouvez utiliser avec le plan de contrôle sont classées en fonction du type de contrôle souhaité, comme suit. Vous pouvez utiliser une ou plusieurs de ces fonctionnalités en fonction de vos besoins spécifiques.

Gestion des clés et des identifiants : contrôlez les clés utilisées par GKE pour chiffrer les données au repos dans le plan de contrôle, et pour émettre et valider les identités dans le cluster.
Journaux d'accès et journaux d'émission d'identité : utilisez les journaux du réseau, des VM et du Access Transparency pour vérifier l'accès au plan de contrôle GKE à l'aide de plusieurs sources. Utilisez les journaux d'émission d'identité dans Cloud KMS et le service d'autorité de certification pour savoir quand des identités sont créées à l'aide de clés et d'autorités de certification que vous gérez. Utilisez des journaux d'utilisation détaillés de l'API Kubernetes pour suivre les actions de ces identités dans le cluster.

Gestion des clés et des identifiants

Par défaut, Google Cloud gère les clés et les CA dans vos clusters GKE. Vous pouvez éventuellement utiliser Cloud KMS et CA Service pour configurer vos propres clés et autorités de certification, que vous utiliserez ensuite lors de la création d'un cluster.

GKE utilise ces clés et ces CA au lieu des valeurs par défaut Google Cloudpour émettre et valider les identités dans votre cluster, et pour chiffrer les données dans vos VM de plan de contrôle. En conservant le contrôle sur vos clés de chiffrement des données et d'émission d'identité, vous pouvez :

Respecter les réglementations sur la souveraineté et la confidentialité des données qui imposent un contrôle exclusif des clés
Contrôlez le chiffrement des données sensibles critiques dans Kubernetes en gérant vos propres clés de chiffrement.
Personnalisez votre stratégie de chiffrement des données en fonction des règles et des exigences de votre organisation, comme l'obligation d'utiliser des clés matérielles.

Autorités de certification autogérées et clés de compte de service

Vous pouvez configurer le plan de contrôle GKE pour qu'il utilise les clés Cloud KMS et les autorités de certification CA Service que vous gérez. GKE utilise ces ressources pour émettre et valider les identités dans votre cluster. Par exemple, GKE utilise des clés et des CA pour émettre des certificats client Kubernetes et des jetons de support de compte de service Kubernetes.

Vous créez les ressources suivantes que GKE utilisera lors de l'émission d'identités :

Clés de signature du compte de service : signent les jetons de support Kubernetes ServiceAccount pour les comptes de service du cluster. Ces jetons de support sont des jetons Web JSON (JWT) qui facilitent la communication des pods avec le serveur d'API Kubernetes.
Clés de validation du compte de service : validez les JWT du compte de service Kubernetes. Cette clé est normalement identique à la clé de signature, mais elle est configurée séparément pour vous permettre de faire tourner vos clés de manière plus sécurisée.
Autorité de certification du cluster : émet des certificats signés pour des besoins tels que les requêtes de signature de certificat (CSR) et la communication kubelet.
CA homologue etcd : émet des certificats signés pour la communication entre les instances etcd du cluster.
CA de l'API etcd : émet des certificats signés pour la communication avec le serveur d'API etcd.
CA d'agrégation : émet des certificats signés pour permettre la communication entre le serveur d'API Kubernetes et les serveurs d'extension.

Lorsque GKE émet des identités dans le cluster, les journaux d'audit correspondants s'affichent dans Cloud Logging. Vous pouvez les utiliser pour suivre les identités émises tout au long de leur cycle de vie.

Pour en savoir plus, consultez Exécuter vos propres autorités de certification et clés de signature dans GKE.

Chiffrement du disque de démarrage et d'etcd du plan de contrôle

Par défaut, GKE chiffre le disque de démarrage d'une VM de plan de contrôle. Si le plan de contrôle exécute des instances de base de données etcd, GKE chiffre également les éléments suivants :

Disque qui stocke les données etcd.
La sauvegarde opérationnelle interne d'etcd. Google Cloud

Ce chiffrement par défaut utilise des clés de chiffrement gérées par Google Cloud . Pour en savoir plus sur ce chiffrement par défaut, consultez Chiffrement au repos par défaut.

Vous pouvez facultativement utiliser vos propres clés de chiffrement que vous gérez à l'aide de Cloud KMS pour chiffrer les ressources suivantes :

Disque de démarrage du plan de contrôle : disque Compute Engine que chaque VM du plan de contrôle utilise pour démarrer.
Disque etcd : disque Compute Engine associé à chaque VM du plan de contrôle et stockant les données des instances etcd du cluster.
Sauvegarde opérationnelle interne d'etcd : sauvegarde interne Google Cloud d'etcd utilisée à des fins opérationnelles, comme la reprise après sinistre.

Cette sauvegarde est une mesure d'urgence interne à Google Cloud. Si vous souhaitez sauvegarder et restaurer vos clusters, utilisez plutôt Sauvegarde pour GKE.

Pour obtenir des instructions, consultez Chiffrer les disques de démarrage etcd et du plan de contrôle.

Ce chiffrement facultatif supplémentaire est idéal si vous devez répondre à des exigences réglementaires ou de conformité spécifiques liées au contrôle des moyens de chiffrement dans le plan de contrôle de votre cluster. Vous pouvez utiliser vos propres clés pour chiffrer séparément les disques de démarrage et les disques de stockage des nœuds de calcul de votre cluster. Pour en savoir plus, consultez Utiliser des clés de chiffrement gérées par le client (CMEK).

Lorsque vous utilisez l'autorité du plan de contrôle GKE pour chiffrer les disques de démarrage de votre plan de contrôle, les VM du plan de contrôle GKE utilisent automatiquement le mode confidentiel pour Hyperdisk Balanced dans les disques de démarrage. Cette configuration ne modifie pas les disques de démarrage par défaut de vos nœuds de calcul.

Journaux d'accès et journaux d'émission d'identité

Vous pouvez afficher les journaux dans Logging pour tous les événements liés à l'accès et à l'identité dans le plan de contrôle, y compris les événements suivants :

Accès direct : les journaux liés aux tentatives d'accès direct (comme SSH) aux nœuds du plan de contrôle GKE vous permettent de vérifier que les journaux SSH des VM et les connexions réseau des VM correspondent aux enregistrements SSH dans les journaux Access Transparency.
Émission et validation d'identités : journaux liés aux identités émises à l'aide des clés et des autorités de certification que vous gérez dans CA Service et Cloud KMS.
Utilisation des identités dans Kubernetes : journaux liés aux actions effectuées par des identités spécifiques sur le serveur d'API Kubernetes.
Access Transparency : journaux liés aux connexions établies avec le plan de contrôle et aux actions effectuées sur le plan de contrôle par le personnel de Google Cloud .

Ces journaux peuvent vous aider à effectuer les opérations suivantes :

Conservez des journaux d'audit complets de tous les accès au plan de contrôle et des événements liés à l'identité pour la conformité et la sécurité.
En plus des protections Google intégrées, vous pouvez créer votre propre surveillance pour identifier et examiner toute activité suspecte dans le plan de contrôle.
Vérifiez que seules les entités autorisées accèdent à votre cluster GKE et interagissent avec lui, ce qui améliore votre niveau de sécurité.
Découvrez quand des identités sont créées à l'aide de clés et d'AC que vous gérez à l'aide des journaux d'émission d'identité dans Cloud KMS et CA Service. Utilisez des journaux d'utilisation détaillés de l'API Kubernetes pour suivre les actions de ces identités dans le cluster.

Les documents suivants vous expliquent comment afficher et traiter les différents types de journaux du plan de contrôle :

Ressources supplémentaires sur la sécurité du plan de contrôle

Cette section décrit d'autres méthodes que vous pouvez utiliser pour renforcer la sécurité de votre plan de contrôle. Vous n'avez pas besoin d'utiliser l'autorité du plan de contrôle GKE pour utiliser les ressources suivantes :

Intégrité de l'image de VM du plan de contrôle : GKE ajoute des journaux détaillés pour les événements de création et de démarrage de VM de nœud à Cloud Logging. De plus, nous publions des VSA SLSA sur GitHub qui correspondent aux images de machine du plan de contrôle et des nœuds de calcul. Vous pouvez vérifier que vos VM utilisent des images d'OS qui ont des VSA correspondantes et valider l'intégrité du démarrage de chaque VM du plan de contrôle.

Pour vérifier l'intégrité des VM, consultez Vérifier l'intégrité des VM du plan de contrôle GKE.
Mesures de sécurité intégrées au plan de contrôle : GKE effectue diverses mesures de renforcement sur le plan de contrôle géré. Pour en savoir plus, consultez la section Sécurité du plan de contrôle.