Cette page explique comment configurer des clés de chiffrement gérées par le client (CMEK) pour un cluster Google Cloud Managed Service pour Apache Kafka.
Présentation du chiffrement des messages
Par défaut, Managed Service pour Apache Kafka chiffre les messages au repos avec Google-owned and Google-managed encryption keys. Aucune configuration supplémentaire n'est requise.
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 pour Apache Kafka, vous pouvez définir une clé CMEK lorsque vous créez votre cluster. Les CMEK sont des clés de chiffrement qui vous appartiennent. Elles sont gérées et stockées dans Cloud Key Management Service (Cloud KMS). Lorsque vous configurez un cluster avec une clé CMEK, le service utilise automatiquement cette clé pour chiffrer toutes les données du cluster au repos. L'utilisation d'une clé 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.
É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 le cluster Kafka.
Rôles et autorisations nécessaires
Le compte de service Managed Kafka doit être autorisé à chiffrer et déchiffrer les données à l'aide d'une clé CMEK.
Attribuez au compte de service le rôle Chiffreur/Déchiffreur de CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) sur la clé Cloud KMS :
gcloud kms keys add-iam-policy-binding KEY \
--keyring=KEY_RING \
--location=LOCATION \
--member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
--role=roles/cloudkms.cryptoKeyEncrypterDecrypter
Remplacez les éléments suivants :
KEY : nom de la clé.
KEY_RING : nom du trousseau de clés où se trouve la clé.
LOCATION : emplacement Cloud KMS du trousseau de clés.
PROJECT_NUMBER : numéro du projetGoogle Cloud contenant le cluster Managed Service pour Apache Kafka.
Pour en savoir plus sur l'attribution de rôles sur une clé Cloud KMS, consultez Attribuer des rôles sur une ressource.
Rotation des clés
Vous ne pouvez pas modifier la clé associée à un cluster. Vous pouvez effectuer une rotation de clé en créant une version de clé et en la définissant 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 la sélection d'une nouvelle version de clé primaire.
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
Vous ne pouvez pas modifier la clé associée à un cluster. Vous pouvez plutôt 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. Il est possible que vous ne puissiez pas utiliser 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.
Étapes suivantes
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 Clés de chiffrement gérées par le client.