Cette page explique comment chiffrer les données stockées dans votre plan de contrôle Google Kubernetes Engine (GKE) à l'aide de clés que vous gérez dans Cloud Key Management Service (Cloud KMS). Vous devez déjà connaître des concepts tels que etcd, l'architecture des clusters GKE et Cloud KMS.
Cette page décrit une partie d'un ensemble de fonctionnalités facultatives du plan de contrôle dans GKE qui vous permet d'effectuer des tâches telles que la vérification de la stratégie de sécurité de votre plan de contrôle ou la configuration du chiffrement et de la signature des identifiants dans le plan de contrôle à l'aide de clés que vous gérez. Pour en savoir plus, consultez la section À propos de l'autorité du plan de contrôle GKE.
Par défaut, Google Cloud applique diverses mesures de sécurité au plan de contrôle géré. Cette page décrit les fonctionnalités facultatives qui vous offrent une meilleure visibilité ou un meilleur contrôle sur le plan de contrôle GKE.
À propos du disque de démarrage du plan de contrôle et du chiffrement etcd
Par défaut, GKE chiffre le disque de démarrage d'un nœud de plan de contrôle, le disque qui stocke les données dans etcd, et la Google Cloud sauvegarde opérationnelle interne d'etcd à l'aide de clés de chiffrement gérées par Google Cloud. Pour en savoir plus sur ce chiffrement par défaut, consultez la section Chiffrement au repos par défaut. Vous pouvez facultatif utiliser vos propres clés de chiffrement que vous gérez à l'aide de Cloud KMS pour chiffrer ces ressources. Pour en savoir plus, consultez la section Disque de démarrage du plan de contrôle et chiffrement etcd.
Vous créez des clés dans Cloud KMS que GKE utilise pour chiffrer vos ressources de plan de contrôle. Tenez compte des points suivants lorsque vous créez ces ressources:
- Vous pouvez utiliser un trousseau pour toutes les clés d'un cluster, quel que soit l'objectif de chaque clé. Si vous disposez d'un trousseau de clés que vous avez utilisé à d'autres fins, comme la configuration de vos propres autorités de certification, vous pouvez l'utiliser pour ce guide.
- Pour une meilleure latence, vous devez créer les clés au même emplacement Google Cloud que votre cluster.
- Pour la plupart des cas d'utilisation, vous pouvez utiliser le niveau de protection de clé Cloud KMS logicielle. Vous pouvez également utiliser des clés matérielles avec Cloud HSM.
- Vous devez spécifier l'indicateur
--purpose
avec la valeurencryption
, car ces clés sont utilisées pour le chiffrement symétrique. - Vous ne devez pas modifier la durée par défaut de destruction des clés.
Utilisation avec d'autres fonctionnalités d'autorité du plan de contrôle GKE
L'autorité du plan de contrôle GKE fournit les fonctionnalités suivantes liées aux clés autogérées que vous devez activer en même temps lorsque vous créez un cluster:
- Chiffrer les composants du plan de contrôle (cette page)
- Exécuter vos propres autorités de certification (CA) et clés
Vous ne pouvez activer ces fonctionnalités que lorsque vous créez un cluster GKE. Vous ne pouvez pas mettre à jour les clusters existants pour utiliser ces fonctionnalités. Pour utiliser ces deux fonctionnalités dans le même cluster, effectuez toutes les procédures de configuration des clés et des autorités de certification dans les deux guides, puis exécutez la commande de création de cluster qui active les deux ensembles de fonctionnalités, comme décrit dans la section Créer un cluster.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update
.
- Assurez-vous que votre projet de clé dispose d'un trousseau Cloud KMS pour votre cluster. Vous pouvez utiliser n'importe quel trousseau de clés existant dans l'emplacement de votre cluster. Pour créer un trousseau de clés, consultez Créer un trousseau de clés.
-
Enable the Cloud Key Management Service API.
Identifier des projets
Nous vous recommandons d'utiliser des projets Google Cloud distincts comme suit:
- Projet de clé: contient toutes les clés.
- Projet de clusters: contient vos clusters GKE.
Vous pouvez utiliser le même projet pour vos clés et vos clusters GKE, mais nous vous recommandons d'utiliser des projets distincts afin que les équipes qui gèrent vos clés et vos opérations cryptographiques soient distinctes de celles qui gèrent vos clusters.
Rôles et autorisations requis
Pour obtenir les autorisations nécessaires pour exécuter vos propres clés de chiffrement, demandez à votre administrateur de vous accorder les rôles IAM suivants:
-
Créez des clés Cloud KMS :
Administrateur Cloud KMS (
roles/cloudkms.admin
) sur votre projet de clé. -
Créer des clusters GKE : Administrateur de cluster Kubernetes Engine (
roles/container.clusterAdmin
) sur votre projet de cluster
Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.
Conditions requises
Votre cluster doit exécuter GKE version 1.31.1-gke.1846000 ou ultérieure.
Limites
- Vous ne pouvez configurer le disque de démarrage et les clés de chiffrement etcd que lors de la création du cluster.
Pour les clusters régionaux en mode Standard et les clusters Autopilot, la région dans laquelle vous créez un cluster doit disposer d'une capacité pour le mode Confidential pour Hyperdisk Balanced dans au moins trois zones de cette région.
Pour les clusters zonaux en mode Standard, la zone du cluster doit disposer d'une capacité Hyperdisk Balanced. Pour obtenir de l'aide concernant la capacité, contactez l'assistance Cloud Customer Care.
Le mode confidentiel pour Hyperdisk Balanced n'est disponible que dans certaines régions. Pour en savoir plus, consultez la section Régions disponibles pour les volumes Hyperdisk Balanced en mode confidentiel.
GKE n'accepte que les clés de Cloud KMS. Vous ne pouvez pas utiliser d'autre fournisseur KMS Kubernetes ni d'autre fournisseur de chiffrement.
Les clés Cloud External Key Manager (Cloud EKM) ne sont pas acceptées.
Vous ne pouvez pas accéder ni interagir avec les sauvegardes opérationnelles internes d'etcd de Google Cloud , qui ne sont destinées qu'à la reprise après sinistre.
Les trousseaux de clés multirégionaux ne sont pas acceptés. Vous devez utiliser un trousseau de clés régional.
Créer des clés
Dans cette section, vous allez créer une clé de chiffrement pour les disques de démarrage et les disques etcd dans votre plan de contrôle, ainsi qu'une clé de chiffrement distincte pour la Google Cloud sauvegarde opérationnelle interne d'etcd. Vous pouvez utiliser un seul trousseau de clés pour contenir toutes ces clés et toute autre clé du cluster.
Créez la clé de chiffrement pour les disques de démarrage et les disques etcd de votre plan de contrôle:
gcloud kms keys create KCP_DISK_KEY_NAME \ --keyring=KEYRING_NAME \ --location=LOCATION \ --purpose="encryption" \ --protection-level=PROTECTION_LEVEL \ --project=KEY_PROJECT_ID
Remplacez les éléments suivants :
KCP_DISK_KEY_NAME
: nom de la clé de chiffrement pour les disques de démarrage et les disques etcd du plan de contrôle.KEYRING_NAME
: nom du trousseau de clés qui contient vos clés de chiffrement pour le cluster.LOCATION
: emplacement Google Cloud du trousseau de clés. Il doit être identique à celui de votre cluster. Pour obtenir la liste des régions, filtrez sur "Région" dans le tableau des emplacements Cloud KMS.PROTECTION_LEVEL
: niveau de protection de la clé, tel quesoftware
ouhsm
.KEY_PROJECT_ID
: ID de votre projet de clé.
Créez la clé de chiffrement de la sauvegarde interne d'etcd:
gcloud kms keys create ETCD_BACKUP_KEY_NAME \ --keyring=KEYRING_NAME \ --location=LOCATION \ --purpose="encryption" \ --protection-level=PROTECTION_LEVEL \ --project=KEY_PROJECT_ID
Remplacez
ETCD_BACKUP_KEY_NAME
par un nom pour la clé de chiffrement de la sauvegarde interne d'etcd.
Attribuer des rôles IAM à l'agent de service GKE
Dans cette section, vous accordez des rôles IAM sur les clés que vous avez créées à l'agent de service GKE dans le projet de cluster. L'agent de service GKE exige que ces rôles utilisent ces clés pour chiffrer les ressources du plan de contrôle correspondantes.
Recherchez le numéro de projet de votre cluster:
gcloud projects describe CLUSTER_PROJECT_ID \ --format='value(projectNumber)'
Remplacez
CLUSTER_PROJECT_ID
par l'ID de projet de votre cluster GKE.Le résultat ressemble à ce qui suit :
1234567890
Accordez le rôle Cloud KMS CryptoKey Encrypter/Decrypter (Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS) (
roles/cloudkms.cryptoKeyEncrypterDecrypter
) sur la clé de chiffrement pour les disques de démarrage et les disques etcd à l'agent de service GKE dans le projet de cluster:gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \ --location=LOCATION \ --keyring=KEYRING_NAME \ --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \ --project=KEY_PROJECT_ID
Remplacez les éléments suivants :
KCP_DISK_KEY_NAME
: nom de la clé de chiffrement de disque.LOCATION
: emplacement Google Cloud de la clé.KEYRING_NAME
: nom du trousseau de clés qui contient la clé de chiffrement.CLUSTER_PROJECT_NUMBER
: numéro de projet numérique du projet de cluster, que vous avez trouvé à l'étape précédente.KEY_PROJECT_ID
: ID de votre projet de clé.
Accordez le rôle Cloud KMS CryptoKey Encrypter/Decrypter Via Delegation (Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS via la délégation) (
roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation
) sur la clé de chiffrement pour les disques de démarrage et les disques etcd à l'agent de service GKE dans le projet de cluster:gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \ --location=LOCATION \ --keyring=KEYRING_NAME \ --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation \ --project=KEY_PROJECT_ID
Accordez le rôle Chiffreur de clés cryptographiques Cloud KMS (
roles/cloudkms.cryptoKeyEncrypter
) sur la clé de chiffrement de sauvegarde interne d'etcd à l'agent de service GKE dans le projet de cluster:gcloud kms keys add-iam-policy-binding ETCD_BACKUP_KEY_NAME \ --location=LOCATION \ --keyring=KEYRING_NAME \ --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \ --role=roles/cloudkms.cryptoKeyEncrypter \ --project=KEY_PROJECT_ID
Remplacez
ETCD_BACKUP_KEY_NAME
par le nom de la clé de chiffrement de la sauvegarde opérationnelle d'etcd.Accorder le rôle
roles/cloudkms.cryptoKeyEncrypter
empêche GKE d'effectuer des restaurations de base de données en votre nom et augmente considérablement le délai de restauration de la fonctionnalité en cas de problème de base de données. Pour autoriser GKE à effectuer des restaurations à votre place, attribuez plutôt le rôleroles/cloudkms.cryptoKeyEncrypterDecrypter
.
Utiliser des clés de chiffrement dans un cluster
Cette section vous explique comment identifier les chemins d'accès à vos clés de chiffrement.
Identifiez le chemin d'accès à votre clé de chiffrement de disque:
gcloud kms keys describe KCP_DISK_KEY_NAME \ --keyring=KEYRING_NAME \ --location=LOCATION \ --project=KEY_PROJECT_ID \ --format="value(name)"
Remplacez les éléments suivants :
KCP_DISK_KEY_NAME
: nom de la clé de chiffrement pour les disques de démarrage du plan de contrôle et les disques etcd.KEYRING_NAME
: nom du trousseau de clés qui inclut la clé.LOCATION
: emplacement Google Cloud de la clé.KEY_PROJECT_ID
: ID de votre projet de clé.
Le résultat ressemble à ce qui suit :
projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/disk-encryption-key
Identifiez le chemin d'accès à votre clé de chiffrement de sauvegarde interne etcd:
gcloud kms keys describe ETCD_BACKUP_KEY_NAME \ --keyring=KEYRING_NAME \ --location=LOCATION \ --project=KEY_PROJECT_ID \ --format="value(name)"
Remplacez
ETCD_BACKUP_KEY_NAME
par le nom de la clé de chiffrement de la sauvegarde opérationnelle d'etcd.Le résultat ressemble à ce qui suit :
projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/etcd-backup-encryption-key
Créer un cluster
Dans cette section, vous allez créer un cluster avec différentes options spécifiées en fonction des fonctionnalités d'autorité du plan de contrôle GKE que vous souhaitez configurer. Vous ne pouvez configurer ces fonctionnalités sur un cluster que lors de sa création. Les commandes suivantes créent des clusters en mode Autopilot. Pour créer des clusters en mode standard, utilisez les mêmes options avec la commande gcloud container clusters create
.
Pour créer un cluster qui configure le chiffrement de disque et exécute vos propres autorités de certification et clés de signature de compte de service, procédez comme suit:
- Suivez toutes les étapes de configuration des clés et des autorités de certification dans la section Exécuter vos propres autorités de certification et clés.
- Recherchez les chemins d'accès à chacune des clés de compte de service et des autorités de certification à l'aide des instructions de la section Configurer des autorités de certification et des clés sur un nouveau cluster.
Créez un cluster :
gcloud container clusters create-auto CLUSTER_NAME \ --location=LOCATION \ --project=CLUSTER_PROJECT_ID \ --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \ --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY \ --service-account-signing-keys=PATH_TO_SIGNING_KEY_VERSION \ --service-account-verification-keys=PATH_TO_VERIFICATION_KEY_VERSION \ --cluster-ca=PATH_TO_CLUSTER_CA \ --etcd-peer-ca=PATH_TO_ETCD_PEER_CA \ --etcd-api-ca=PATH_TO_ETCD_API_CA \ --aggregation-ca=PATH_TO_AGGREGATION_CA
Remplacez les éléments suivants :
CLUSTER_NAME
: nom de votre nouveau clusterLOCATION
: emplacement de votre nouveau cluster.CLUSTER_PROJECT_ID
: ID de projet de votre projet de cluster.PATH_TO_DISK_KEY
: chemin d'accès à votre clé de chiffrement de disque à partir des étapes précédentes de cette page.PATH_TO_ETCD_BACKUP_KEY
: chemin d'accès à votre clé de chiffrement de sauvegarde interne etcd des étapes précédentes de cette page.PATH_TO_SIGNING_KEY_VERSION
: chemin d'accès à la version de la clé de signature du compte de service Kubernetes dans Cloud KMS.PATH_TO_VERIFICATION_KEY_VERSION
: chemin d'accès à la version de la clé de validation du compte de service Kubernetes dans Cloud KMS.PATH_TO_CLUSTER_CA
: chemin d'accès au pool d'autorités de certification du cluster.PATH_TO_ETCD_PEER_CA
: chemin d'accès au pool d'autorités de certification de paires etcd.PATH_TO_ETCD_API_CA
: chemin d'accès au pool d'autorités de certification de l'API etcd.PATH_TO_AGGREGATION_CA
: chemin d'accès au pool d'autorités de certification d'agrégation.
Pour créer un cluster qui ne configure que le chiffrement de disque à l'aide des clés que vous avez créées dans ce guide, exécutez la commande suivante:
gcloud container clusters create-auto CLUSTER_NAME \ --location=LOCATION \ --project=CLUSTER_PROJECT_ID \ --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \ --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
Remplacez les éléments suivants :
CLUSTER_NAME
: nom de votre nouveau clusterLOCATION
: emplacement de votre nouveau cluster.CLUSTER_PROJECT_ID
: ID de projet de votre projet de cluster.PATH_TO_DISK_KEY
: chemin d'accès à votre clé de chiffrement de disque des étapes précédentes.PATH_TO_ETCD_BACKUP_KEY
: chemin d'accès à votre clé de chiffrement de sauvegarde interne etcd des étapes précédentes.
Vous pouvez également spécifier tous ces indicateurs lorsque vous créez un cluster en mode standard.
Vérifier l'état de la clé de chiffrement
Cette section explique comment vérifier la clé de chiffrement utilisée lors de la création du cluster. Vous pouvez effectuer cette vérification à l'aide de Cloud Logging ou de Google Cloud CLI.
Utiliser Logging pour valider les clés
Pour vérifier les clés à l'aide de Logging, procédez comme suit:
Dans la console Google Cloud , accédez à la page Explorateur de journaux:
Obtenez le journal de création du cluster en spécifiant la requête suivante:
resource.type="gke_cluster" resource.labels.cluster_name="CLUSTER_NAME" resource.labels.location="CLUSTER_LOCATION" protoPayload.serviceName="container.googleapis.com" protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster" protoPayload.request.cluster.userManagedKeysConfig:*
Cliquez sur Exécuter la requête.
Dans la sortie, vérifiez que les paramètres de création du cluster incluent un chemin de clé correspondant à la clé que vous avez configurée dans Cloud KMS, comme dans l'exemple suivant:
# lines omitted for clarity
userManagedKeysConfig: {
controlPlaneDiskEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/KCP_DISK_KEY_NAME"
gkeopsEtcdBackupEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/ETCD_BACKUP_KEY_NAME"
}
Vérifier les clés à l'aide de gcloud CLI
Pour utiliser la gcloud CLI pour valider la clé de chiffrement, procédez comme suit:
Pour la clé de chiffrement de disque, exécutez la commande suivante:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --format="value(userManagedKeysConfig.controlPlaneDiskEncryptionKey)"
Pour la clé de chiffrement de la sauvegarde interne d'etcd, exécutez la commande suivante:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --format="value(userManagedKeysConfig.gkeopsEtcdBackupEncryptionKey)"
Étape suivante
- En savoir plus sur les autres éléments que vous pouvez afficher dans le plan de contrôle
- Exécuter vos propres autorités de certification et clés dans GKE
- Vérifier l'intégrité de la VM du plan de contrôle