Chiffrer les secrets au niveau de la couche d'application

Autopilot Standard

---

Découvrez comment chiffrer les objets Secret Kubernetes au niveau de la couche d'application, au moyen d'une clé que vous gérez via le service Cloud Key Management Service (Cloud KMS). Dans la mesure où cette fonctionnalité repose sur Cloud KMS, vous devez vous familiariser avec la rotation des clés et le chiffrement encapsulé.

---

Pour obtenir des instructions détaillées sur cette tâche directement dans la console Google Cloud, cliquez sur Visite guidée :

Visite guidée

---

Présentation

Par défaut, Google Kubernetes Engine (GKE) chiffre le contenu client stocké au repos, y compris les secrets. GKE traite et gère ce chiffrement par défaut sans requérir aucune action de votre part.

Le chiffrement des secrets au niveau de la couche d'application fournit une couche de sécurité supplémentaire pour les données sensibles stockées dans etcd, telles que les secrets. Vous utilisez une clé gérée avec Cloud KMS pour chiffrer les données au repos au niveau de la couche d'application. Elle offre une protection contre les pirates informatiques qui réussiraient à accéder à une copie hors connexion d'etcd.

Pour utiliser le chiffrement des secrets au niveau de la couche d'application, vous devez d'abord créer une clé Cloud KMS et permettre au compte de service GKE d'y accéder. Vous pouvez utiliser une clé dotée de l'un des niveaux de protection compatibles avec Cloud KMS.

Vérifiez que la clé se trouve au même emplacement que le cluster afin de réduire la latence et d'éviter que les ressources ne dépendent de services répartis sur plusieurs domaines de défaillance. Après avoir créé une clé, vous pouvez activer la fonctionnalité sur un cluster nouveau ou existant en spécifiant la clé que vous souhaitez utiliser. Lorsque vous activez cette fonctionnalité, GKE chiffre tous les secrets nouveaux et existants à l'aide de votre clé de chiffrement.

Remarque : Lorsque vous utilisez des clés CMEK dans GKE, vos projets peuvent utiliser des quotas de requêtes de chiffrement Cloud KMS. Par exemple, GKE peut utiliser ces quotas lors du chiffrement ou du déchiffrement d'une clé de chiffrement des données dans GKE à l'aide d'une clé de chiffrement de clé de Cloud KMS. Les opérations de chiffrement et de déchiffrement à l'aide de clés CMEK n'affectent les quotas Cloud KMS que si vous utilisez des clés matérielles (Cloud HSM) ou externes (Cloud EKM). Pour en savoir plus, consultez la page Quotas Cloud KMS.

Chiffrement encapsulé

Kubernetes propose le chiffrement encapsulé des secrets via un fournisseur KMS, ce qui signifie qu'ils sont chiffrés à l'aide d'une clé locale, couramment appelée clé de chiffrement de données (DEK, Data Encryption Key). Cette DEK est elle-même chiffrée au moyen d'une autre clé appelée clé de chiffrement de clé (KEK, Key Encryption Key), Kubernetes ne stocke pas la clé KEK.

Le chiffrement encapsulé présente les avantages suivants :

• Performances améliorées par rapport au chiffrement par clé publique : GKE n'utilise l'API Cloud KMS que pour chiffrer les nouvelles DEK avec la KEK ou pour déchiffrer une DEK lorsque le cache local est vide.
• Meilleure gestion des clés à grande échelle : une seule KEK peut chiffrer plusieurs DEK. Le nombre de clés que vous devez stocker dans le service Cloud KMS est nettement inférieur au nombre de clés qui chiffrent vos données.
• Capacité à utiliser une racine de confiance centrale : les secrets stockés dans Kubernetes peuvent être basés sur une racine de confiance externe. Cela signifie que vous pouvez utiliser une racine de confiance centrale, telle qu'un module de sécurité matérielle, pour tous vos secrets. Une personne mal intentionnée accédant à vos conteneurs hors connexion ne peut pas obtenir vos secrets.

Avec le chiffrement des secrets au niveau de la couche d'application dans GKE, GKE chiffre vos secrets à l'aide des DEK locales et du fournisseur AES-CBC. GKE chiffre les DEK avec une KEK que vous gérez dans Cloud KMS.

Pour en savoir plus sur le chiffrement encapsulé, consultez la page Chiffrement encapsulé.

Que se passe-t-il lorsque vous créez un secret ?

La création d'un secret met en œuvre le processus suivant :

1. Le serveur d'API Kubernetes génère une DEK unique pour le nouveau secret à l'aide d'un générateur de numéros aléatoires.

2. Le serveur d'API Kubernetes utilise cette DEK localement pour chiffrer le secret.

3. Le plug-in KMS envoie la DEK à Cloud KMS pour chiffrement. Le plug-in KMS s'authentifie auprès de Cloud KMS à l'aide du compte de service GKE de votre projet.

4. Cloud KMS chiffre la DEK à l'aide de la KEK et la renvoie au plug-in KMS.

5. Le serveur d'API Kubernetes enregistre le secret et la DEK chiffrés. La DEK en texte brut n'est pas enregistrée sur un disque et n'est stockée que dans la mémoire du serveur d'API.

6. Le serveur d'API Kubernetes crée une entrée de cache mappant la DEK chiffrée avec la DEK en texte brut en mémoire. Cela permet au serveur d'API de déchiffrer le secret sans utiliser Cloud KMS.

Lorsqu'un client demande un secret au serveur d'API Kubernetes, voici ce qui se passe :

1. Le serveur d'API Kubernetes récupère le secret et la DEK chiffrés.

2. Le serveur d'API Kubernetes vérifie le cache d'une entrée de mappage existante et déchiffre le secret sans utiliser Cloud KMS.

3. Si une entrée de cache est introuvable, le plug-in KMS envoie la DEK à Cloud KMS pour déchiffrement à l'aide de la KEK. La DEK déchiffrée est ensuite utilisée pour déchiffrer le secret.

4. Le serveur d'API Kubernetes renvoie le secret déchiffré au client.

Que se passe-t-il lorsque vous détruisez une clé ?

Avertissement : La destruction d'une clé n'est pas réversible. Les données chiffrées avec la version détruite ne pourront pas être récupérées.

Lorsque vous détruisez une KEK dans Cloud KMS utilisée pour chiffrer un secret dans GKE, celui-ci n'est plus disponible, sauf si vous mettez à jour le cluster pour utiliser une nouvelle KEK au préalable.

Si vous envisagez de détruire une ancienne version de KEK après une rotation des clés, utilisez d'abord la nouvelle version de KEK pour rechiffrer le secret. Vous pouvez éventuellement conserver la version précédente de KEK pour éviter de rechiffrer les secrets, mais vous continuez à être facturé pour toutes les KEK actives dans Cloud KMS. Pour en savoir plus, consultez la page Tarifs de Cloud KMS.

Remarque : Ne détruisez les versions précédentes de KEK que lorsque vous êtes sûr qu'aucune donnée de votre cluster n'est chiffrée à l'aide de la version précédente. Avant de détruire une KEK, vérifiez si celle-ci est utilisée. Pour en savoir plus, consultez la page Détruire et restaurer des versions de clé.

À moins que vous n'ayez recours à une projection de volume de jeton du compte de service, les comptes de service utilisés par vos charges de travail sur GKE exploitent également des secrets, et si une clé est détruite, ils deviennent indisponibles. Si vous ne pouvez pas accéder aux secrets, les charges de travail échoueront.

Les exceptions suivantes s'appliquent :

• Les pods avec un accès existant aux secrets en tant que volumes installés ou variables d'environnement conservent l'accès.

• Le serveur d'API Kubernetes peut toujours utiliser les entrées de mappage DEK mises en cache pour déchiffrer un secret après la destruction de la KEK. Cela permet aux pods redémarrés ou reprogrammés d'accéder au secret, sauf dans les cas suivants :

  • Le plan de contrôle du cluster est redémarré.
  • Le pod du serveur d'API Kubernetes est redémarré.
  • L'entrée de mappage DEK pour le secret ne se trouve pas dans le cache du serveur d'API Kubernetes.

Avant de détruire une KEK, vérifiez si elle est utilisée par votre cluster. Vous pouvez également créer une règle d'alerte pour la destruction de clés dans Cloud KMS.

Avant de commencer

• Pour réaliser les exercices de ce thème, vous avez besoin de deux projets Google Cloud.

  • Projet de clé : c'est ici que vous allez créer une KEK.

  • Projet de cluster : c'est ici que vous allez créer un cluster activant le chiffrement des secrets au niveau de la couche d'application.

  Remarque : Vous pouvez utiliser le même projet pour votre projet de clé et votre projet de cluster. Il est toutefois recommandé d'utiliser des projets distincts.

• Dans votre projet de clé, assurez-vous que vous avez activé l'API Cloud KMS.

  Activer l'API Cloud KMS

• Dans votre projet de clé, l'utilisateur qui crée le trousseau de clés et la clé doit disposer des autorisations IAM suivantes :

  • cloudkms.keyRings.getIamPolicy
  • cloudkms.keyRings.setIamPolicy

  Ces autorisations (et bien d'autres encore) sont accordées au rôle Identity and Access Managementroles/cloudkms.admin prédéfini. Pour en savoir plus sur l'octroi d'autorisations pour gérer les clés, consultez la documentation Cloud KMS.

• Dans votre projet de cluster, vérifiez que vous avez activé l'API Google Kubernetes Engine.

  Activer l'API Google Kubernetes Engine

• Assurez-vous d'avoir installé Google Cloud CLI.

• Mettez à jour gcloud vers la dernière version :

  gcloud components update

Créer une clé Cloud KMS

Pour créer une clé Cloud KMS, vous devez d'abord créer un trousseau de clés. Les clés et les trousseaux de clés sont des ressources régionales. Lorsque vous créez un trousseau de clés, spécifiez un emplacement correspondant à celui de votre cluster GKE :

• Un cluster zonal doit utiliser un trousseau de clés provenant de l'emplacement correspondant au surensemble de sa région. Par exemple, un cluster situé dans la zone us-central1-a ne peut utiliser qu'une clé de la région us-central1.

• Un cluster régional doit utiliser un trousseau de clés localisé dans son emplacement. Par exemple, un cluster situé dans la région asia-northeast1 doit être protégé par un trousseau de clés provenant de la région asia-northeast1.

Remarque : La région global de Cloud KMS n'est pas compatible avec GKE.

Vous pouvez utiliser gcloud CLI ou Google Cloud Console.

Console

Dans votre projet de clé, créez un trousseau de clés :

1. Accédez à la page Gestion des clés dans la console Google Cloud.

   Accéder à Key Management

2. Cliquez sur Créer un trousseau.

3. Dans le champ Key ring name (Nom du trousseau), saisissez le nom du trousseau de clés.

4. Dans la liste déroulante Location (Emplacement), sélectionnez l'emplacement de votre cluster Kubernetes.

5. Cliquez sur Create (Créer).

Ensuite, créez une clé :

1. Accédez à la page Gestion des clés dans la console Google Cloud.

   Accéder à Key Management

2. Cliquez sur le nom du trousseau de clés pour lequel vous souhaitez créer une clé.

3. Cliquez sur Créer une clé.

4. Dans le champ Key name (Nom de la clé), saisissez le nom de votre clé.

5. Acceptez les valeurs par défaut pour Rotation period (Période de rotation) et Starting on (Rotation à partir du), ou définissez une période de rotation des clés et une date de début si vous souhaitez utiliser des valeurs différentes.

6. [Facultatif] Dans le champ Labels (Étiquettes), cliquez sur Add label (Ajouter une étiquette) si vous souhaitez ajouter des étiquettes à la clé.

7. Cliquez sur Create (Créer).

gcloud

Dans votre projet de clé, créez un trousseau de clés :

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

Remplacez les éléments suivants :

• RING_NAME : nom de votre nouveau trousseau de clés
• LOCATION : emplacement dans lequel vous souhaitez créer le trousseau de clés
• KEY_PROJECT_ID : identifiant de votre projet de clé

Créez une clé :

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

Remplacez les éléments suivants :

• KEY_NAME : nom de votre nouvelle clé
• LOCATION : emplacement Cloud KMS dans lequel vous avez créé votre trousseau de clés.
• RING_NAME : nom de votre trousseau de clés
• KEY_PROJECT_ID : identifiant de votre projet de clé

Accorder l'autorisation d'utiliser la clé

Le compte de service GKE de votre projet de cluster porte le nom suivant :

[e-mail]

Remplacez CLUSTER_PROJECT_NUMBER par le numéro de projet de votre cluster. Pour trouver votre numéro de projet à l'aide de gCloud CLI, exécutez la commande suivante :

gcloud projects describe CLUSTER_PROJECT_ID \
    --format="value(projectNumber)"

Pour accorder l'accès au compte de service, vous pouvez utiliser Google Cloud Console ou gcloud CLI.

Console

Attribuez à votre compte de service GKE le rôle de chiffreur/déchiffreur de clés cryptographiques Cloud KMS :

1. Ouvrez le navigateur Clés Cloud Key Management Service dans Google Cloud Console.
   Ouvrir le navigateur de clés Cloud KMS

2. Cliquez sur le nom du trousseau contenant la clé souhaitée.

3. Cochez la case correspondant à la clé souhaitée.

   L'onglet Autorisations s'affiche dans le volet de droite.

4. Dans la boîte de dialogue Ajouter des membres, indiquez l'adresse e-mail du compte de service GKE auquel vous accordez l'accès.

5. Dans le menu déroulant Sélectionner un rôle, sélectionnez Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS.

6. Cliquez sur Enregistrer.

gcloud

Attribuez à votre compte de service GKE le rôle de chiffreur/déchiffreur de clés cryptographiques Cloud KMS :

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

Remplacez l'élément suivant :

• KEY_NAME : nom de votre clé
• LOCATION : emplacement Cloud KMS dans lequel vous avez créé votre trousseau de clés.
• RING_NAME : nom de votre trousseau de clés
• SERVICE_ACCOUNT_NAME : nom de votre compte de service GKE
• KEY_PROJECT_ID : identifiant de votre projet de clé

Vérifier que le quota de la clé est suffisant s'il s'agit d'une clé Cloud HSM

Si vous utilisez une clé Cloud HSM, le projet Google Cloud qui contient la clé est limité par votre quota de clés. Assurez-vous de disposer d'un quota suffisant pour utiliser vos clés Cloud HSM avec le chiffrement des secrets au niveau de la couche d'application. Si votre quota est épuisé, vos nœuds risquent de perdre la connectivité à votre plan de contrôle de cluster.

Activer le chiffrement des secrets au niveau de la couche d'application

Vous pouvez activer le chiffrement des secrets au niveau de la couche d'application sur les clusters GKE Standard et GKE Autopilot, nouveaux ou existants, à l'aide de gcloud CLI ou de la console Google Cloud.

Une fois le chiffrement des secrets au niveau de la couche d'application activé, nous vous recommandons d'effectuer une rotation des clés. Vous pouvez configurer la rotation automatique des clés dans Cloud KMS. Pour obtenir des instructions, consultez la section Configurer la rotation automatique.

Sur un nouveau cluster

Vous pouvez créer un cluster avec le chiffrement des secrets au niveau de la couche d'application activé à l'aide de la console Google Cloud ou de gcloud CLI.

Console (Autopilot)

Pour créer un cluster Autopilot avec le chiffrement des secrets au niveau de la couche d'application activé, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

3. Dans la section Autopilot, cliquez sur Configurer.

4. Configurez le cluster selon vos besoins.

5. Dans le volet de navigation, cliquez sur Options avancées, puis développez la section Sécurité.

6. Sélectionnez la case à cocher Activer le chiffrement des secrets au niveau de la couche d'application, puis choisissez la clé que vous avez créée à la section Créer une clé Cloud KMS.

7. Cliquez sur Créer.

Console (Standard)

Pour créer un cluster standard avec le chiffrement des secrets au niveau de la couche d'application activé, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

3. Dans la section Standard, cliquez sur Configurer.

4. Configurez le cluster selon vos besoins.

5. Dans le volet de navigation, cliquez sur Sécurité sous Cluster.

6. Sélectionnez la case à cocher Activer le chiffrement des secrets au niveau de la couche d'application, puis choisissez la clé que vous avez créée à la section Créer une clé Cloud KMS.

7. Cliquez sur Create (Créer).

gcloud

Pour créer un cluster compatible avec le chiffrement des secrets au niveau de la couche d'application, spécifiez une valeur pour le paramètre --database-encryption-key dans votre commande de création.

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

• CLUSTER_NAME correspond au nom que vous avez choisi pour votre cluster.
• COMPUTE_REGION : région Compute Engine dans laquelle vous souhaitez créer le cluster
• KEY_PROJECT_ID : identifiant de votre projet de clé
• LOCATION : emplacement Cloud KMS dans lequel vous avez créé votre trousseau de clés.
• RING_NAME : nom de votre trousseau de clés
• KEY_NAME : nom de votre clé
• CLUSTER_PROJECT_ID : ID de votre projet de votre cluster

Vous pouvez activer le chiffrement des secrets au niveau de la couche d'application sur un nouveau cluster Standard à l'aide de la commande gcloud container clusters create avec les mêmes options.

Sur un cluster existant

Vous pouvez utiliser gcloud CLI ou Google Cloud Console pour mettre à jour un cluster existant afin d'utiliser le chiffrement des secrets au niveau de la couche d'application. GKE chiffre tous vos secrets, aussi bien ceux existants que les nouveaux, à l'aide de la clé de chiffrement que vous avez spécifiée.

Important : La mise à jour d'un cluster existant de sorte qu'il utilise le chiffrement des secrets au niveau de la couche d'application entraîne le redémarrage du plan de contrôle du cluster. Pour les clusters zonaux, le plan de contrôle devient indisponible.

Console

Pour mettre à jour un cluster de sorte qu'il soit compatible avec le chiffrement des secrets au niveau de la couche d'application :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Sécurité, dans le champ Chiffrement des secrets au niveau de la couche d'application, cliquez sur Modifier le chiffrement des secrets au niveau de la couche d'application.

4. Sélectionnez la case à cocher Activer le chiffrement des secrets au niveau de la couche d'application, puis choisissez la clé que vous avez créée à l'étape Créer une clé Cloud KMS.

5. Cliquez sur Enregistrer les modifications.

gcloud

Pour activer le chiffrement des secrets au niveau de la couche d'application sur un cluster existant, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• COMPUTE_REGION : région Compute Engine du cluster.
• KEY_PROJECT_ID : identifiant de votre projet de clé
• LOCATION : emplacement Cloud KMS dans lequel vous avez créé votre trousseau de clés.
• RING_NAME : nom de votre trousseau de clés
• KEY_NAME : nom de votre clé
• CLUSTER_PROJECT_ID : ID de votre projet de votre cluster

Mettre à jour une clé Cloud KMS

Vous pouvez mettre à jour un cluster existant pour qu'il utilise une nouvelle clé Cloud KMS à l'aide de gcloud CLI ou de Google Cloud Console.

Important : La mise à jour d'un cluster existant de sorte qu'il utilise une nouvelle clé Cloud KMS redémarre le plan de contrôle du cluster. Pour les clusters zonaux, le plan de contrôle devient indisponible.

Console

Pour mettre à jour un cluster de sorte qu'il utilise une nouvelle clé Cloud KMS, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Sécurité, dans le champ Chiffrement des secrets au niveau de la couche d'application, cliquez sur Modifier le chiffrement des secrets au niveau de la couche d'application.

4. Sélectionnez la nouvelle clé de chiffrement que vous souhaitez utiliser.

5. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

Mettez à jour votre cluster existant de sorte qu'il utilise une nouvelle clé Cloud KMS :

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Remplacez l'élément suivant :

• CLUSTER_NAME : nom du cluster
• COMPUTE_REGION : région Compute Engine du cluster.
• KEY_PROJECT_ID : identifiant de votre projet de clé
• LOCATION : emplacement Cloud KMS dans lequel vous avez créé votre trousseau de clés.
• RING_NAME : nom de votre trousseau de clés
• KEY_NAME : nom de votre clé
• CLUSTER_PROJECT_ID : ID de votre projet de votre cluster

Désactiver "Chiffrement des secrets au niveau de la couche d'application"

Pour désactiver le chiffrement des secrets au niveau de la couche d'application, vous pouvez utiliser gcloud CLI ou Google Cloud Console.

Console

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Sécurité, dans le champ Chiffrement des secrets au niveau de la couche d'application, cliquez sur Modifier le chiffrement des secrets au niveau de la couche d'application.

4. Décochez la case Activer le chiffrement des secrets au niveau de la couche d'application.

5. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

Pour désactiver le chiffrement des secrets au niveau de la couche d'application, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• COMPUTE_REGION : région Compute Engine du cluster.
• CLUSTER_PROJECT_ID : ID de votre projet de votre cluster

Confirmer l'activation du chiffrement des secrets au niveau de la couche d'application

Vous pouvez vérifier si un cluster utilise le chiffrement des secrets au niveau de la couche d'application à l'aide de la console Google Cloud ou de gcloud CLI.

Console

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Sécurité, vérifiez que le champ Chiffrement des secrets au niveau de la couche d'application affiche Enabled et répertorie la clé correcte.

gcloud

Pour vérifier si un cluster utilise le chiffrement des secrets au niveau de la couche d'application :

gcloud container clusters describe CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• COMPUTE_REGION : région Compute Engine du cluster.
• CLUSTER_PROJECT_ID : ID de votre projet de votre cluster

Si le cluster utilise le chiffrement des secrets au niveau de la couche d'application, le résultat ressemble à ce qui suit :

keyName=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME;state=ENCRYPTED

Effectuer la rotation de vos clés

Nous vous recommandons d'effectuer régulièrement une rotation des clés, y compris après avoir activé le chiffrement des secrets au niveau de la couche d'application. Pour obtenir des instructions sur la configuration de la rotation automatique des clés ou sur la rotation manuelle des clés, consultez la page Effectuer une rotation des clés.

Lorsque vous effectuez une rotation des clés, vos secrets existants restent chiffrés avec la version précédente de la clé de chiffrement de clé (KEK). Pour vous assurer qu'une version plus récente de la clé KEK encapsule un secret, rechiffrez le secret après la rotation des clés.

Par exemple, créez un secret nommé Secret1 et stockez-le. Il est chiffré avec DEK1, elle-même encapsulée avec KEKv1.

Après la rotation de la KEK, vous rechiffrez Secret1 afin qu'elle soit encapsulée par DEK2, qui à son tour est encapsulée avec KEKv2, la KEK qui a fait l'objet d'une rotation.

Remarque : La rotation des versions de clé est une opération cohérente à terme, et un délai peut être nécessaire avant que la nouvelle version de clé ne prenne effet. Nous vous recommandons d'attendre au moins trois heures avant de rechiffrer vos secrets après une rotation. Pour plus d'informations, consultez la section Cohérence des versions de clé.

Rechiffrer les secrets

Après avoir effectué une rotation des clés, vous devez rechiffrer vos secrets pour les encapsuler dans la nouvelle version de la clé KEK. Bien que vous ne puissiez pas configurer le rechiffrement automatique à l'aide de gCloud CLI, vous pouvez, par exemple, utiliser une tâche Cron pour exécuter la commande de rechiffrement à intervalles réguliers.

Pour rechiffrer manuellement vos secrets après une rotation des clés, attendez au moins trois heures pour que la nouvelle version devienne cohérente. Ensuite, passez sur chaque secret pour forcer le rechiffrement à l'aide d'une commande telle que :

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Remplacez TIME par une chaîne indiquant à quel moment la rotation se produit (par exemple, 20200909-090909).

Remarque : L'ancienne version de la clé continue à exister et à entraîner des frais. Si l'ancienne version n'est plus utilisée, vous pouvez la détruire. La destruction de la version de clé est permanente. Par conséquent, veillez à rechiffrer vos secrets avant de le faire.

Limites

• GKE accepte jusqu'à 30 000 secrets par cluster pour le chiffrement des secrets au niveau de la couche d'application. Si vous stockez plus de 30 000 secrets, votre cluster peut devenir instable au moment de la mise à niveau, ce qui risque d'entraîner une interruption de vos charges de travail.
• Assurez-vous que la taille moyenne des métadonnées d'un secret dans chaque espace de noms est inférieure à 5 Kio. Si la taille moyenne des métadonnées est supérieure à 5 Kio, il est possible que votre cluster se retrouve dans un état incorrect, où certains secrets sont chiffrés pendant que d'autres sont déchiffrés après avoir activé la fonctionnalité ou désactivé cette fonctionnalité.

• Vous devez sélectionner une clé localisée dans la même région que le cluster. Par exemple, un cluster zonal situé dans us-central1-a ne peut utiliser qu'une clé située dans la région us-central1. Pour les clusters régionaux, les clés doivent se trouver au même emplacement afin de réduire la latence et d'éviter que les ressources ne dépendent de services répartis sur plusieurs domaines de défaillance.

  Remarque : La clé ne doit pas obligatoirement se trouver dans le même projet que le cluster. Pour plus d'informations sur les emplacements compatibles avec Cloud KMS, consultez la page Emplacements Google Cloud.

• 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.

Dépannage

Pour en savoir plus sur la résolution des problèmes de chiffrement des secrets au niveau de la couche application, y compris sur la résolution des problèmes liés aux mises à jour de chiffrement des secrets ayant échoué, consultez la page Résoudre les problèmes de chiffrement des secrets au niveau de la couche application.

La clé Cloud KMS est désactivée

Le compte de service par défaut de GKE ne peut pas utiliser une clé Cloud KMS désactivée pour le chiffrement des secrets au niveau de l'application.

Pour réactiver une clé, consultez la page Activer une version de clé désactivée.

Étape suivante

• Approfondissez vos connaissances sur les secrets Kubernetes.
• Apprenez-en davantage plus sur la gestion des secrets à l'aide de Cloud KMS.
• Découvrez comment renforcer la sécurité de votre cluster.