Some or all of the information on this page might not apply to Trusted Cloud by S3NS.

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

Chiffrer les disques de démarrage d'etcd et du plan de contrôle

Autopilot Standard

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 l'une des fonctionnalités facultatives du plan de contrôle dans GKE. Elle 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 À propos de l'autorité du plan de contrôle GKE.

Par défaut, Trusted 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 visibilité ou un contrôle accrus sur le plan de contrôle GKE.

À propos du 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'un nœud du plan de contrôle, le disque qui stocke les données dans etcd et la sauvegarde opérationnelle interne d'etcd à l'aide de clés de chiffrement gérées par Trusted Cloud. Trusted Cloud Trusted Cloud by S3NS 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 ces ressources. Pour en savoir plus, consultez Chiffrement du disque de démarrage et d'etcd du plan de contrôle.

Vous créez des clés dans Cloud KMS que GKE utilise pour chiffrer les ressources de votre plan de contrôle. Tenez compte des points suivants lorsque vous créez ces ressources :

Vous pouvez utiliser un trousseau de clés pour toutes les clés d'un cluster, quel que soit l'objectif de chaque clé. Si vous disposez déjà d'un trousseau de clés que vous avez utilisé à d'autres fins, comme pour configurer 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 Trusted Cloud que votre cluster.
Dans la plupart des cas d'utilisation, vous pouvez utiliser le niveau de protection logiciel des clés Cloud KMS. Vous pouvez également utiliser des clés matérielles avec Cloud HSM.
Vous devez spécifier l'indicateur --purpose avec la valeur encryption, car ces clés sont utilisées pour le chiffrement symétrique.
Vous ne devez pas modifier la durée par défaut avant destruction des clés.

Utilisation avec d'autres fonctionnalités de l'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 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 de l'autorité 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.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si l'emplacement de votre cluster diffère de celui par défaut que vous avez défini.

Assurez-vous que votre projet de clé comporte un trousseau de clés 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.
Enable the API

Identifier des projets

Nous vous recommandons d'utiliser des projets Trusted Cloud distincts comme suit :

Projet de clé : contient toutes les clés.
Projet de clusters : contient vos clusters GKE.

Vous pouvez éventuellement 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 de chiffrement 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) dans votre projet de clés
Créez 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 Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec 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 les clés de chiffrement du disque de démarrage et d'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 confidentiel 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 équilibrée. Pour obtenir de l'aide concernant la capacité, contactez Cloud Customer Care.
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 aux sauvegardes opérationnelles internes d'etcd ni interagir avec elles. Elles sont réservées à la reprise après sinistre. Trusted Cloud
Les trousseaux de clés multirégionaux ne sont pas acceptés. Vous devez utiliser un trousseau de clés régional.
Les régions et les zones dans lesquelles vous pouvez utiliser l'autorité du plan de contrôle GKE dépendent des fonctionnalités spécifiques que vous souhaitez également utiliser :
- 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 Trusted Cloud .

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 de votre plan de contrôle, ainsi qu'une clé de chiffrement distincte pour la sauvegarde opérationnelle interne d'etcd Trusted Cloud. Vous pouvez utiliser un trousseau de clés pour stocker toutes ces clés et toutes les autres clés du cluster.

Créez la clé de chiffrement pour vos disques de démarrage et etcd du 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 vos disques de démarrage et disques etcd du plan de contrôle.
- KEYRING_NAME : nom du trousseau de clés qui contiendra vos clés de chiffrement pour le cluster.
- LOCATION : emplacement Trusted Cloud du trousseau de clés. Il doit être identique à l'emplacement 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 que software ou hsm.
- KEY_PROJECT_ID : ID de projet de votre projet de clé.

Créez la clé de chiffrement interne de sauvegarde 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 le nom de la clé de chiffrement interne de sauvegarde etcd.

Attribuer des rôles IAM à l'agent de service GKE

Dans cette section, vous allez attribuer des rôles IAM aux clés que vous avez créées pour l'agent de service GKE dans le projet de cluster. L'agent de service GKE a besoin de ces rôles pour utiliser ces clés afin de chiffrer les ressources de plan de contrôle correspondantes.

Recherchez le numéro de votre projet de 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
```
Attribuez le rôle Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) sur la clé de chiffrement des disques de démarrage et des disques etcd à l'agent de service GKE dans le projet du 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.s3ns-system.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 du disque.
- LOCATION : emplacement Trusted 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 du cluster, que vous avez trouvé à l'étape précédente.
- KEY_PROJECT_ID : ID de projet de votre projet de clé.

Attribuez le rôle Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS via délégation (roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation) sur la clé de chiffrement des disques de démarrage et etcd à l'agent de service GKE dans le projet du 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.s3ns-system.iam.gserviceaccount.com" \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation \
    --project=KEY_PROJECT_ID

Accordez le rôle Utilisateur de clé Cloud KMS sur les clés de chiffrement des disques de démarrage et des disques etcd à l'agent de service GKE dans le projet de cluster pour la rotation des clés :

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.s3ns-system.iam.gserviceaccount.com" \
    --role=roles/container.cloudKmsKeyUser \
    --project=KEY_PROJECT_ID

Attribuez le rôle Chiffreur de clés cryptographiques Cloud KMS (roles/cloudkms.cryptoKeyEncrypter) sur la clé de chiffrement interne des sauvegardes etcd à l'agent de service GKE dans le projet du 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.s3ns-system.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 sauvegarde opérationnelle etcd.

L'attribution du 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 temps nécessaire pour restaurer les fonctionnalités en cas de problème de base de données. Pour autoriser GKE à effectuer des restaurations pour vous, accordez plutôt le rôle roles/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 : Trusted Cloud emplacement de la clé.
- KEY_PROJECT_ID : ID de projet 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 interne de sauvegarde 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 sauvegarde opérationnelle 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 Standard. Pour créer des clusters en mode Autopilot, utilisez les mêmes indicateurs avec la commande gcloud container clusters create-auto.

Pour créer un cluster qui configure le chiffrement de disque et exécute vos propres clés de signature d'autorité de certification et de compte de service, procédez comme suit :
1. Effectuez toutes les étapes de configuration des clés et de l'autorité de certification dans Exécuter vos propres autorités de certification et clés.
2. Recherchez les chemins d'accès à chacune des clés de compte de service et des CA en suivant les instructions de la section Configurer des CA et des clés sur un nouveau cluster.
3. Créez un cluster :
```
gcloud container clusters create 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 cluster
  - LOCATION : 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 à partir 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 homologues 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 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 cluster
- LOCATION : 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 vous 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 valider les clés à l'aide de Logging, procédez comme suit :

Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

Accéder à l'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 le résultat, vérifiez que les paramètres de création du cluster incluent un chemin d'accès à la clé qui correspond à 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"
}

Utiliser gcloud CLI pour valider les clés

Pour utiliser la gcloud CLI afin de vérifier la clé de chiffrement, procédez comme suit :

Pour la clé de chiffrement du disque, exécutez la commande suivante :

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(userManagedKeysConfig.controlPlaneDiskEncryptionKey)"

Pour la clé de chiffrement de sauvegarde interne etcd, exécutez la commande suivante :

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(userManagedKeysConfig.gkeopsEtcdBackupEncryptionKey)"