Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

Autopilot Standard

Ce document 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 GKE control plane authority. Ce document est destiné aux responsables de la sécurité des informations, aux administrateurs de la conformité et aux analystes qui souhaitent répondre à des besoins stricts en matière de confidentialité et de sécurité pour le traitement des données sensibles.

À propos des fonctionnalités de GKE control plane authority

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

GKE control plane authority 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 une meilleure visibilité sur GKE pour renforcer votre 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 avez des charges de travail très sensibles qui traitent des données critiques, et vous souhaitez avoir une 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 un niveau de transparence et de visibilité accru dans vos environnements GKE, en particulier en ce qui concerne les actions effectuées par Cloud de Confiance dans le plan de contrôle.

Avantages de GKE control plane authority

Les fonctionnalités de GKE control plane authority sont idéales dans les environnements hautement réglementés qui sont soumis à des règles de sécurité strictes ou à des exigences d'audit strictes. L'utilisation de ces fonctionnalités offre les avantages suivants :

Visibilité et contrôle améliorés : utilisez des 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 par Cloud de Confiance dans le plan de contrôle lors de la résolution des demandes d'assistance client.
Atténuation des risques : détectez de manière proactive les menaces potentielles pour le plan de contrôle géré et réagissez-y 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, ce qui vous permet de déléguer la gestion des certificats à des équipes spécifiques et d'appliquer de manière exhaustive les règles des autorités de certification. De plus, gérez les clés de chiffrement de votre disque de plan de contrôle à l'aide de Cloud KMS pour une délégation de gestion similaire.

Disponibilité de GKE control plane authority

GKE control plane authority est disponible dans toutes les Cloud de Confiance régions. Toutefois, pour chiffrer vos disques de démarrage du plan de contrôle et vos disques etcd avec vos propres clés, vous devez créer le cluster dans l'une des régions suivantes :

asia-east1
asia-northeast1
asia-southeast1
europe-west1
europe-west4
us-central1
us-central2
us-east1
us-east4
us-east5
us-south1
us-west1
us-west3
us-west4

Fonctionnement de GKE control plane authority

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, ainsi que 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, de la VM, et d'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 CA Service pour voir 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 effectuées par ces identités dans le cluster.

Gestion des clés et des identifiants

Par défaut, Cloud de Confiance gère les clés et les autorités de certification dans vos clusters GKE. Vous pouvez également 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 autorités de certification au lieu des Cloud de Confiance valeurs par défaut pour émettre et valider les identités dans votre cluster, ainsi que pour chiffrer les données dans vos VM de plan de contrôle. Le fait de conserver le contrôle sur vos clés d'émission d'identité et de chiffrement des données peut vous aider à effectuer les opérations suivantes :

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

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 autorités de certification et des clés pour émettre des certificats clients Kubernetes et des jetons de support de compte de service Kubernetes.

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

Clés de signature de compte de service : signez 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 de compte de service : validez les JWT de compte de service Kubernetes. Cette clé est normalement identique à la clé de signature, mais elle est configurée séparément afin que vous puissiez faire pivoter vos clés de manière plus sécurisée.
Autorité de certification de cluster : émettez des certificats signés à des fins telles que les demandes de signature de certificat (CSR) et la communication kubelet.
Autorité de certification de pair etcd : émettez des certificats signés pour la communication entre les instances etcd du cluster.
Autorité de certification de l'API etcd : émettez des certificats signés pour la communication avec le serveur d'API etcd.
Autorité de certification d'agrégation : émettez des certificats signés pour activer la communication entre le serveur d'API Kubernetes et les serveurs d'extension.

Lorsque GKE émet des identités dans le cluster, vous voyez les journaux d'audit correspondants dans Cloud Logging, que vous pouvez 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 du plan de contrôle et d'etcd

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 :

Le disque qui stocke les données etcd.
La Cloud de Confiance by S3NS sauvegarde opérationnelle interne d'etcd.

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

Vous pouvez également 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 de plan de contrôle utilise pour démarrer.
Disque etcd : disque Compute Engine associé à chaque VM de plan de contrôle et qui stocke les données des instances etcd du cluster.
Sauvegarde opérationnelle interne d'etcd : sauvegarde Cloud de Confiance interne d'etcd utilisée à des fins opérationnelles, comme la reprise après sinistre.

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

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

Ce chiffrement facultatif supplémentaire est idéal si vous devez respecter des exigences réglementaires ou de conformité spécifiques liées au contrôle des moyens de chiffrement dans votre plan de contrôle de cluster. Vous pouvez utiliser vos propres clés séparément pour chiffrer 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 GKE control plane authority pour chiffrer vos disques de démarrage du plan de contrôle, les VM de 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.

Rotation des identifiants gérés par le client

Avec GKE control plane authority, vous pouvez configurer des clusters pour qu'ils utilisent des autorités de certification et des clés gérées par le client au lieu des ressources gérées par Google que GKE utilise par défaut. Une rotation des identifiants est une opération que vous effectuez pour actualiser une ou plusieurs de ces ressources dans un cluster. Vous pouvez effectuer une rotation des identifiants pour éviter l'expiration de l'autorité de certification ou pour respecter les exigences de gestion des identifiants de votre organisation.

Pour effectuer une rotation des identifiants pour un cluster qui utilise GKE control plane authority, vous créez des autorités de certification, des clés de signature et des clés de chiffrement. Vous mettez ensuite à jour votre cluster pour qu'il utilise ces nouvelles ressources.

Pour en savoir plus, consultez les pages suivantes :

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 de plan de contrôle GKE vous permettent de vérifier que les journaux SSH de la VM et les connexions réseau de la VM correspondent aux enregistrements SSH dans les journaux Access Transparency.
Émission et validation d'identité : journaux liés aux identités émises à l'aide d'autorités de certification et de clés 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 Cloud de Confiance personnel. Lorsque l'approbation d'accès augmentée est activée, vous bénéficiez d'une granularité accrue pour le contrôle des accès, y compris les détails des commandes SSH dans les journaux Access Transparency et pour les demandes d'approbation d'accès. Pour en savoir plus sur l'éligibilité et l'inscription, contactez l'équipe chargée de votre Cloud de Confiance by S3NS compte.

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

Conserver des pistes d'audit complètes de tous les événements d'accès et d'identité du plan de contrôle à des fins de conformité et de 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érifier que seules les entités autorisées accèdent à votre cluster GKE et interagissent avec lui, ce qui améliore votre stratégie de sécurité.
Voir quand des identités sont créées à l'aide de clés et d'autorités de certification que vous gérez en utilisant les journaux d'émission d'identité dans Cloud KMS et CA Service. Utiliser des journaux d'utilisation détaillés de l'API Kubernetes pour suivre les actions effectuées par ces identités dans le cluster.

Les documents suivants vous montrent 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 votre confiance dans la sécurité de votre plan de contrôle. Vous n'avez pas besoin d'utiliser GKE control plane authority 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 la création de VM de nœud et les événements de démarrage à 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 de l'OS qui ont des VSA correspondants et vérifier l'intégrité du démarrage de chaque VM de plan de contrôle.

Pour effectuer la validation de 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 du plan de contrôle : GKE effectue diverses mesures de renforcement sur le plan de contrôle géré. Pour en savoir plus, consultez Sécurité du plan de contrôle.