Cette page décrit les méthodes d'authentification compatibles pour les applications clientes qui se connectent aux courtiers Google Cloud Managed Service pour Apache Kafka.
Pour les applications clientes Google Cloud Managed Service pour Apache Kafka exécutées sur des services Google Cloud tels que Google Kubernetes Engine, Compute Engine, Cloud Run ou Cloud Run Functions, vous disposez des options d'authentification suivantes :
SASL/OAUTHBEARER (recommandé) : il s'agit de la méthode la plus fluide et la plus sécurisée pour les clients dans Google Cloud. Il utilise les identifiants par défaut de l'application (ADC) pour trouver automatiquement l'identité du compte de service associée à l'environnement. Cela évite d'avoir à gérer et distribuer des fichiers d'identifiants statiques tels que les clés de compte de service.
SASL/PLAIN : méthode utile pour les premières étapes du développement. Le client s'authentifie à l'aide d'une clé de compte de service de longue durée.
mTLS : cette option est disponible si la norme de votre organisation est l'authentification basée sur les certificats. Votre application sur Google Cloud est configurée avec un certificat et une clé client.
Pour les applications clientes s'exécutant en dehors de Google Cloud, par exemple dans un centre de données sur site ou sur un autre fournisseur de services cloud, envisagez les méthodes d'authentification suivantes. Choisissez la méthode la mieux adaptée à la posture de sécurité et à l'infrastructure d'identité existantes de votre organisation.
Fédération d'identité de charge de travail avec SASL/OAUTHBEARER (recommandé) : il s'agit de la méthode la plus sécurisée pour les clients externes. Elle vous permet d'accorder aux identités de systèmes externes, tels qu'AWS, Microsoft Azure ou un fournisseur d'identité sur site comme ADFS, la possibilité d'emprunter l'identité d'un compte de serviceGoogle Cloud . Au lieu de gérer des clés de compte de service à longue durée de vie, le client utilise ses identifiants préférés pour obtenir un jeton d'accès Google Cloud éphémère. Le client utilise ensuite ce jeton pour l'authentification, ce qui réduit considérablement le risque de sécurité associé aux fichiers d'identifiants statiques.
mTLS : cette méthode est indépendante du fournisseur et convient si votre organisation utilise déjà une infrastructure à clé publique (PKI) pour gérer les certificats TLS pour l'identité de service. Il permet aux clients de s'authentifier sans identité spécifique à Google Cloud. Toutefois, comme pour les clés de compte de service, cette approche nécessite de gérer le cycle de vie et la distribution des identifiants de longue durée, tels que les certificats client.
SASL/PLAIN avec une clé de compte de service : cette méthode permet à un client externe de s'authentifier directement en tant qu'identité Google Cloud . Vous téléchargez un fichier JSON de clé de compte de service et l'utilisez dans la configuration SASL/PLAIN de votre client. Cette méthode est généralement déconseillée pour les charges de travail de production, car elle nécessite de gérer et de sécuriser une identifiant statique de longue durée côté client.
Comparaison des fonctionnalités entre SASL et mTLS
Le principal mécanisme d'authentification pour Managed Service pour Apache Kafka est SASL (Simple Authentication and Security Layer), qui s'intègre directement aux services d'identité deGoogle Cloud. En règle générale, SASL authentifie les clients à l'aide d'un compte principal IAM Google Cloud , tel qu'un compte de service. Pour l'autorisation, SASL offre de la flexibilité : vous pouvez gérer l'accès aux clusters à l'aide de rôles IAM précis et des listes de contrôle d'accès (LCA) de Kafka.
En revanche, mTLS offre une méthode d'authentification indépendante du fournisseur qui ne repose pas sur Google Cloud IAM. Au lieu de cela, mTLS authentifie un client en fonction de son certificat TLS, où l'identité est dérivée du nom du sujet du certificat.
Cette distinction entraîne une différence majeure dans la façon dont l'autorisation est gérée. Contrairement aux comptes principaux SASL, les comptes principaux mTLS doivent être autorisés à l'aide des LCA Kafka exclusivement. Ils ne peuvent pas être gérés avec les rôles IAM Google Cloud .
Nous vous recommandons vivement de configurer les LCA Kafka pour votre cluster. Si aucune LCA n'est définie, le comportement Kafka par défaut accorde à tous les comptes principaux authentifiés (qu'ils utilisent SASL ou mTLS) un accès complet au cluster. Pour savoir comment configurer les LCA Kafka, consultez Créer une LCA Managed Service pour Apache Kafka.
Managed Service for Apache Kafka est compatible avec l'authentification mTLS avec des certificats client émis par des autorités de certification disponibles dans CA Service. Si votre organisation utilise une racine de confiance externe, vous pouvez l'intégrer en créant une autorité de certification subordonnée dans CA Service qui est associée à votre autorité de certification externe.
Le tableau suivant compare les fonctionnalités des méthodes d'authentification.
| Fonctionnalité | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| Identité principale | Google Cloud Compte principal IAM | Google Cloud Compte principal IAM | Nom de l'objet du certificat |
| Type d'identifiants | Identifiants par défaut de l'application (ADC) ou jeton OAuth 2.0 | Clé de compte de service encodée en base64 | Certificat client et clé privée |
| Méthode d'autorisation | Google Cloud Rôles IAM ou LCA Kafka | Google Cloud Rôles IAM ou LCA Kafka | LCA Kafka uniquement |
| Cas d'utilisation | Clients sur Google Cloud ; clients externes utilisant la fédération d'identité de charge de travail | Clients simples, scénarios de test ou systèmes anciens pour lesquels l'utilisation d'une clé de compte de service est requise. | Indépendant du fournisseur ; idéal pour les applications sur site, multicloud ou PKI existantes. |
| Configuration du client | Configuration JAAS avec une classe de gestionnaire de connexion spécialisée (Java) ou un serveur d'authentification local (non Java) | Configuration JAAS avec PlainLoginModule standard (Java) | Propriétés du keystore et du truststore (par exemple, security.protocol=SSL) |
| Disponibilité du cluster | Tous les clusters | Tous les clusters | Clusters créés après le 24 juin 2025 |
Choisir entre SASL et mTLS
Le choix de la méthode d'authentification dépend des règles de sécurité et de l'infrastructure existante de votre organisation. Dans la plupart des cas d'utilisation, nous vous recommandons d'utiliser SASL avec IAM. Google Cloud
SASL avec Google Cloud IAM ou la fédération d'identité de charge de travail offre l'expérience d'authentification et d'autorisation la plus flexible et intégrée. Il utilise le système d'identité de Google Cloudcomme source unique de vérité pour gérer les autorisations. Choisissez cette option si vous souhaitez :
Gérez de façon centralisée les autorisations de vos clients Kafka à l'aide des rôles IAMGoogle Cloud que vous connaissez.
Évitez de gérer les identifiants statiques sur les clients.
Permettez aux clients d'autres clouds, comme AWS ou Azure, ou de fournisseurs d'identité sur site, comme Okta ou ADFS, de s'authentifier à l'aide de la fédération d'identité de charge de travail. Cette méthode fournit une solution d'identité sécurisée et indépendante du cloud, sans avoir à passer à un autre protocole d'authentification.
Choisissez mTLS si votre organisation a une exigence stricte en matière d'authentification basée sur les certificats. Cette nécessité se présente lorsque vous migrez un déploiement Kafka sur site existant qui utilise déjà des certificats TLS pour l'identité, ou lorsque la politique de l'entreprise exige des certificats client pour toutes les applications. Bien que mTLS offre une sécurité de niveau transport élevée, n'oubliez pas que l'autorisation pour les clients mTLS doit être gérée exclusivement avec les LCA Kafka, qui sont distinctes d' Google Cloud IAM.
Workflow pour configurer SASL/PLAIN ou SASL/OAUTHBEARER
Pour configurer un client afin qu'il utilise l'authentification SASL avec Managed Service pour Apache Kafka, vous devez accorder des autorisations à l'identité du client, puis configurer l'application cliente en fonction du mécanisme SASL choisi. Vous trouverez ci-dessous une vue d'ensemble du workflow requis. Pour obtenir des instructions détaillées sur la configuration de SASL, consultez Configurer l'authentification SASL.
Accordez des autorisations IAM. Vous devez d'abord attribuer le rôle Client Kafka géré (
roles/managedkafka.client) au compte de service que votre client utilise pour l'authentification. Ce rôle fournit l'autorisationmanagedkafka.clusters.connectnécessaire pour se connecter aux clusters Kafka du projet.Configurez le client Kafka. La configuration spécifique du client dépend de l'utilisation du mécanisme SASL/OAUTHBEARER ou SASL/PLAIN.
Pour SASL/OAUTHBEARER (recommandé) : ce mécanisme utilise les identifiants par défaut de l'application (ADC). La configuration dépend de la langue de votre client :
Clients Java : ajoutez la bibliothèque d'authentification Google Cloud spécialisée au classpath de votre application. Ensuite, configurez les propriétés du client Kafka pour utiliser la classe
GcpLoginCallbackHandlerfournie, qui gère automatiquement l'authentification à l'aide d'ADC.GcpLoginCallbackHandlerest une classe utilisée avec le mécanisme d'authentification OAUTHBEARER de Kafka, spécialement conçue pour être utilisée avec Managed Service pour Apache Kafka. Il gère le processus d'obtention d'un jeton Web JSON (JWT) auprès du fournisseur d'identité de Google, ce qui permet aux clients Kafka de s'authentifier auprès du service à l'aide de l'ADC.Clients non Java : exécutez un serveur d'authentification local fourni sur la machine du client. Ce serveur utilise ADC pour récupérer les identifiants et les fournit au client Kafka. Le client est ensuite configuré pour obtenir son jeton d'authentification à partir du point de terminaison de ce serveur local.
Pour SASL/PLAIN
Ce mécanisme utilise une combinaison de nom d'utilisateur et de mot de passe. L'application cliente doit être configurée pour utiliser le protocole de sécurité SASL_SSL, le mécanisme PLAIN et une configuration JAAS qui spécifie la classe
PlainLoginModule.Le nom d'utilisateur correspond à l'adresse e-mail du compte de service. Le mot de passe peut être généré de deux manières :
En encodant en base64 un fichier JSON de clé de compte de service.
en obtenant un jeton d'accès éphémère.
Configurez les autorisations. Une fois qu'un client s'est authentifié avec succès à l'aide de SASL, son accès est contrôlé par les autorisations définies dans les rôles IAM ou les LCA Kafka sur le cluster.
Limites SASL
La méthode d'authentification SASL présente les limites suivantes :
L'authentification SASL est intrinsèquement liée aux principaux IAM. Elle ne convient pas aux organisations qui ont besoin d'une séparation stricte de l'identitéGoogle Cloud ou qui utilisent des identités non Google, sauf si vous configurez la fédération d'identité de charge de travail.
SASL n'utilise pas de certificats client pour l'authentification. Elle ne convient pas directement aux organisations qui s'appuient sur une infrastructure à clé publique existante pour identifier les applications.
Workflow de configuration de mTLS
La configuration de mTLS pour Managed Service pour Apache Kafka implique la configuration des autorités de certification, du cluster Kafka et de vos clients Kafka. Pour obtenir des instructions détaillées sur la configuration de mTLS, consultez Configurer l'authentification mTLS.
Configurer les autorités de certification (CA) Vous devez d'abord créer et configurer des pools d'autorités de certification dans Certificate Authority Service (CA Service). Si vous créez des pools d'autorités de certification dans un autre projet, assurez-vous d'accorder à l'agent de service Managed Service pour Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) l'autorisation d'accéder à ces pools. Vous devez créer des certificats racine et subordonnés dans les pools d'autorités de certification.Configurez le cluster Kafka. Créez ou mettez à jour votre cluster pour activer mTLS en fournissant les identifiants de ressources de vos pools d'autorité de certification configurés. Nous vous recommandons également de configurer la propriété de broker
ssl.principal.mapping.rulespour créer des noms de comptes principaux simplifiés à utiliser dans les LCA. Pour ce faire, utilisez les commandes Google Cloud CLI.Configurez les clients Kafka. Obtenez des certificats clients auprès de vos autorités de certification et installez-les dans l'environnement de votre client, par exemple dans un keystore Java. L'application cliente doit ensuite être configurée avec le protocole de sécurité (SSL) approprié et l'emplacement de son keystore pour se connecter au port d'amorçage mTLS dédié du cluster, qui est
9192.Surveillez mTLS. Après la configuration, surveillez la métrique
managedkafka.googleapis.com/mtls_truststore_update_countpour vérifier que le cluster actualise correctement ses certificats CA à partir des pools du service CA, ce qu'il tente de faire régulièrement. Vous pouvez également utiliser Cloud Logging.
Limites de mTLS
La fonctionnalité mTLS présente les limites suivantes :
Vous ne pouvez utiliser la fonctionnalité mTLS que sur les clusters Managed Service pour Apache Kafka créés après le 24 juin 2025.
Vous devez configurer l'autorisation pour les principaux mTLS à l'aide des LCA Kafka. Vous ne pouvez pas utiliser les liaisons de rôle IAM pour autoriser les clients mTLS.
Le service n'authentifie que les clients qui présentent des certificats gérés par CA Service. Toutefois, vous pouvez intégrer une racine de confiance externe en créant une autorité de certification subordonnée dans CA Service qui s'enchaîne à votre autorité de certification externe.
Vous pouvez configurer un cluster pour qu'il fasse confiance à un maximum de 10 pools d'autorité de certification.