Ce document explique comment configurer des clés de chiffrement gérées par le client (CMEK) pour un cluster Google Cloud Managed Service for Apache Kafka.
Managed Service pour Apache Kafka chiffre les messages au repos avec Google-owned and Google-managed encryption keys par défaut. Aucune configuration supplémentaire n'est requise pour utiliser Google-owned and Google-managed encryption keys.
À propos de CMEK
Les CMEK sont des clés de chiffrement qui vous appartiennent et qui sont gérées et stockées dans Cloud Key Management Service (Cloud KMS). Si vous avez besoin de plus de contrôle sur les clés de chiffrement utilisées pour protéger les données au repos de Managed Service for Apache Kafka, vous pouvez utiliser des CMEK.
Lorsque vous configurez un cluster Managed Service pour Apache Kafka avec une clé CMEK, le service chiffre automatiquement toutes les données au repos du cluster à l'aide de la clé spécifiée. L'utilisation de Cloud KMS pour CMEK peut entraîner des coûts supplémentaires en fonction de vos habitudes d'utilisation.
Une CMEK associée à un cluster Managed Service pour Apache Kafka est une clé de chiffrement de clé (KEK). La KEK est utilisée pour chiffrer une clé de chiffrement des données (DEK). La clé DEK est ensuite utilisée pour lire et écrire des données au repos sur des disques persistants associés à des courtiers et des données dans le stockage hiérarchisé de Cloud Storage.
Pour en savoir plus sur le chiffrement des disques, consultez À propos du chiffrement des disques. Pour en savoir plus sur le chiffrement dans Cloud Storage, consultez la page Clés de chiffrement gérées par le client dans la documentation Cloud Storage.
Rotation des clés
Pour effectuer une rotation de clé, vous pouvez créer une version de clé et la définir comme version principale de la clé.
Pour les disques associés aux courtiers, la nouvelle clé KEK ne prend effet qu'après le redémarrage d'un courtier. Vous pouvez forcer le redémarrage progressif des courtiers en mettant à jour la configuration de la capacité d'un cluster. Par exemple, vous pouvez modifier la quantité de RAM du cluster.
Tous les nouveaux fichiers de segments de partition sont écrits dans le stockage hiérarchisé à l'aide de la nouvelle version de clé principale. Un délai de plusieurs minutes peut s'écouler après le choix d'une nouvelle version de clé primaire.
Configurer un cluster Managed Service pour Apache Kafka pour CMEK
Vous pouvez configurer CMEK pour un cluster Managed Service for Apache Kafka à l'aide de la consoleGoogle Cloud ou de Google Cloud CLI.
Avant de commencer
Effectuez les tâches suivantes :
Activez l'API Cloud KMS.
Créez un trousseau de clés et une clé dans Cloud KMS. Les clés et les trousseaux de clés ne peuvent pas être supprimés. Étant donné que les ressources Managed Service pour Apache Kafka sont régionales, nous vous recommandons de créer des CMEK dans la même région que celle où se trouve le cluster Kafka.
Pour savoir comment effectuer ces tâches, consultez le guide de démarrage rapide de Cloud KMS.
Rôles et autorisations requis pour configurer CMEK
Managed Service pour Apache Kafka utilise un agent de service Google Cloudpour accéder à Cloud KMS. L'agent de service de votre projet Google Cloudest automatiquement créé après la création de votre premier cluster Managed Service pour Apache Kafka.
L'agent de service est géré en interne par Managed Service pour Apache Kafka pour chaque projet. Il n'est pas visible sur la page Comptes de service de la console Google Cloud par défaut.
L'agent de service Managed Service pour Apache Kafka se présente sous la forme service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com.
Managed Service pour Apache Kafka nécessite des autorisations spécifiques pour chiffrer et déchiffrer les données à l'aide de CMEK.
Pour configurer l'accès requis, procédez comme suit :
Facultatif : Créez manuellement l'agent de service Managed Service pour Apache Kafka à l'aide de la commande gcloud beta services identity create.
Si vous avez déjà créé un cluster dans votre projet, l'agent de service Managed Service pour Apache Kafka est déjà créé dans votre projet et vous pouvez ignorer cette étape.
gcloud beta services identity create \ --service=managedkafka.googleapis.com \ --project=PROJECT_IDRemplacez PROJECT_ID par l'ID du projet.
Attribuez le rôle Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS (
roles/cloudkms.cryptoKeyEncrypterDecrypter) à l'agent de service Managed Service pour Apache Kafka.gcloud kms keys add-iam-policy-binding CLOUD_KMS_KEY_NAME \ --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypterRemplacez les éléments suivants :
CLOUD_KMS_KEY_NAME : nom de la clé Cloud KMS.
La clé est au format
projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY.Exemple :
projects/test-project/locations/us-central1/keyRings/test-keyring/cryptoKeys/test-key.PROJECT_NUMBER : numéro du projet Managed Service pour Apache Kafka.
Pour en savoir plus sur l'attribution de rôles IAM, consultez Attribuer des rôles sur une ressource.
Créer un cluster avec CMEK
Vous pouvez utiliser la console Google Cloud ou la gcloud CLI pour ajouter vos clés de chiffrement lorsque vous créez votre cluster Kafka.
Enable the Apache Kafka for BigQuery, Compute Engine, Cloud DNS, and Cloud KMS APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role (roles/serviceusage.serviceUsageAdmin), which
contains the serviceusage.services.enable permission. Learn how to grant
roles.
Avant de créer un cluster, consultez la documentation sur les propriétés du cluster.
Pour créer un cluster avec CMEK, procédez comme suit :
Console
-
Dans la console Google Cloud , accédez à la page Clusters.
- Sélectionnez Créer.
La page Créer un cluster Kafka s'ouvre.
- Dans le champ Nom du cluster, saisissez une chaîne.
Pour en savoir plus sur la façon de nommer un cluster, consultez les consignes de dénomination des ressources Managed Service pour Apache Kafka.
- Dans le champ Emplacement, saisissez un emplacement compatible.
Pour en savoir plus sur les emplacements compatibles, consultez Emplacements Managed Service pour Apache Kafka compatibles.
- Pour la configuration de la capacité, saisissez des valeurs pour Mémoire et Processeurs virtuels.
Le ratio entre les processeurs virtuels et la mémoire doit être compris entre 1:1 et 1:8.
Pour en savoir plus sur le dimensionnement d'un cluster Managed Service pour Apache Kafka, consultez Planifier la taille de votre cluster Kafka.
- Dans Configuration réseau, saisissez les informations suivantes :
- Projet : projet dans lequel se trouve le sous-réseau. Le sous-réseau doit se trouver dans la même région que le cluster, mais le projet peut être différent.
- Réseau : réseau auquel le sous-réseau est connecté.
- Sous-réseau : nom du sous-réseau.
- Chemin d'URI du sous-réseau : ce champ est renseigné automatiquement. Vous pouvez également saisir le chemin d'accès au sous-réseau ici. Le nom du sous-réseau doit respecter le format suivant :
projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_ID. - Cliquez sur OK.
- (Facultatif) Ajoutez d'autres sous-réseaux en cliquant sur Ajouter un sous-réseau connecté.
Vous pouvez ajouter d'autres sous-réseaux, jusqu'à un maximum de dix.
- Pour Chiffrement, sélectionnez Clé Cloud KMS.
- Pour Type de clé, sélectionnez Cloud KMS, puis, pour Sélectionner une clé gérée par le client, saisissez la clé CMEK que vous avez créée.
- Cliquez sur Créer.
gcloud
Exécutez la commande
gcloud managed-kafka clusters create:gcloud managed-kafka clusters create CLUSTER_ID \ --location=LOCATION \ --cpu=CPU \ --memory=MEMORY \ --subnets=SUBNETS \ --encryption-key=CLOUD_KMS_KEY \
Remplacez les éléments suivants :
-
CLUSTER_ID : ID ou nom du cluster.
Pour en savoir plus sur la façon de nommer un cluster, consultez les consignes de dénomination des ressources Managed Service pour Apache Kafka.
-
LOCATION : emplacement du cluster.
Pour en savoir plus sur les emplacements compatibles, consultez Emplacements Managed Service pour Apache Kafka compatibles.
-
CPU : nombre de processeurs virtuels pour le cluster. Le ratio entre les processeurs virtuels et la mémoire doit être compris entre 1:1 et 1:8.
Pour en savoir plus sur le dimensionnement d'un cluster Managed Service pour Apache Kafka, consultez Planifier la taille de votre cluster Kafka.
-
MEMORY : quantité de mémoire pour le cluster. Utilisez les unités "MB", "MiB", "GB", "GiB", "TB" ou "TiB". Par exemple, "10 Gio".
-
SUBNETS : liste des sous-réseaux auxquels se connecter. Utilisez des virgules pour séparer plusieurs valeurs de sous-réseau.
Le format du sous-réseau est
projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_ID. -
ENCRYPTION_KEY : ID de la clé CMEK à utiliser pour le cluster.
Il a le format suivant :
projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Confirmer la création du cluster
Vérifiez que le cluster est configuré pour CMEK en exécutant la commande gcloud managed-kafka clusters describe.
gcloud managed-kafka clusters describe CLUSTER_ID \
--location=LOCATION
La sortie inclut la clé CMEK configurée.
Journaux d'audit
Cloud KMS génère des journaux d'audit lorsque les clés sont activées, désactivées ou utilisées par Managed Service pour Apache Kafka pour chiffrer et déchiffrer les messages. Cela s'avère utile pour résoudre les problèmes de disponibilité de la publication ou de la diffusion.
Les ID de clés Cloud KMS sont associés aux journaux d'audit pour les ressources de cluster Managed Service pour Apache Kafka. Managed Service pour Apache Kafka n'inclut aucune autre information associée à Cloud KMS dans les journaux d'audit.
Désactiver et réactiver CMEK
Il existe deux façons de désactiver CMEK. Sélectionnez l'une des méthodes suivantes :
Désactivez la clé Cloud KMS que vous avez associée au cluster. Cette approche affecte toutes les ressources Cloud associées à cette clé.
Révoquez le rôle Chiffreur/Déchiffreur de CryptoKey de l'agent de service Managed Service for Apache Kafka (
service-${PROJECT_NUMBER}@gcp-sa-managedkafka.iam.gserviceaccount.com) à l'aide d'Identity and Access Management (IAM). Cette approche affecte tous les clusters Managed Service pour Apache Kafka du projet, ainsi que les messages chiffrés à l'aide de CMEK.
Même si aucune de ces opérations ne garantit une révocation immédiate des accès, les modifications de Cloud IAM se propagent généralement plus rapidement.
Pour en savoir plus, consultez les pages Cohérence des ressources Cloud KMS et Propagation des modifications d'accès.
Lorsque Managed Service for Apache Kafka ne peut pas accéder à une clé Cloud KMS, la publication et la distribution des messages échouent et génèrent des erreurs. Pour reprendre la diffusion et la publication, rétablissez l'accès à la clé Cloud KMS.
Une fois la clé Cloud KMS accessible à Managed Service pour Apache Kafka, la publication est disponible sous 12 heures et la distribution des messages reprend dans les deux heures.
Bien que les pannes intermittentes de Cloud KMS de moins d'une minute ne risquent pas d'interrompre de manière significative la publication et la livraison, l'indisponibilité prolongée de Cloud KMS a le même effet qu'une révocation de clé.
Limites
L'association entre une clé Cloud KMS et un cluster Managed Service pour Apache Kafka est immuable. Vous ne pouvez pas modifier la clé associée à un cluster. Vous pouvez effectuer une rotation de la clé en créant de nouvelles versions.
Si vous désactivez une version de clé non principale, les disques locaux continuent de fonctionner sans aucun changement. Chaque courtier télécharge la nouvelle clé KEK lors de son redémarrage. Toutefois, Cloud Storage ne peut pas accéder aux fichiers de segments de sujets chiffrés avec la version d'origine, ce qui peut rendre impossible la consommation des messages de ces fichiers de segments. Cela signifie que vous ne pourrez peut-être pas consommer les données plus anciennes.
Si vous désactivez la version principale d'une clé, les courtiers ne peuvent pas écrire de nouveaux fichiers de segment dans le stockage hiérarchisé, ce qui augmente l'utilisation du disque local. De plus, les redémarrages de brokers échoueront. Vous pouvez déclencher un redémarrage de manière proactive ou à tout moment lors d'une mise à jour du cluster initiée par le service.
Si vous supprimez l'accès à une clé de l'agent de service Managed Service pour Apache Kafka, le comportement est semblable à celui qui se produit si vous désactivez à la fois la version de clé principale et les versions de clé non principales.
Si vous supprimez une clé, le cluster est programmé pour l'arrêt et ne peut pas être récupéré.
Vous ne pouvez pas demander le rechiffrement des données stockées au repos. La CMEK est utilisée comme KEK, mais le rechiffrement nécessite une modification des clés de chiffrement des données.