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 : il s'agit d'une méthode utile pour les premières étapes du développement. Le client s'authentifie à l'aide d'une clé de compte de service à longue durée de vie.
mTLS : cette option est disponible si la norme de votre organisation est l'authentification basée sur les certificats. Votre application sur Google Cloudest configurée avec un certificat et une clé client.
Pour les applications clientes exécutées en dehors de Google Cloud, par exemple dans un centre de données sur site ou chez un autre fournisseur de services cloud, envisagez les méthodes d'authentification suivantes. Choisissez la méthode la mieux adaptée à la stratégie 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 à courte durée de vie. 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é du service. Il permet aux clients de s'authentifier sans identité spécifique à Google Cloud. Toutefois, comme pour l'utilisation de clés de compte de service, cette approche vous oblige à 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 un 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 de 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 exclusivement à l'aide des LCA Kafka. Ils ne peuvent pas être gérés avec les rôles IAM Google Cloud .
Nous vous recommandons vivement de configurer des LCA Kafka pour votre cluster. Si aucune LCA n'est définie, le comportement Kafka par défaut accorde à tous les 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 pour 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 Principal IAM | Google Cloud 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é des clusters | 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. Pour la plupart des cas d'utilisation, nous vous recommandons d'utiliser SASL avec Google Cloud IAM.
SASL avec Google Cloud IAM ou la fédération d'identité de charge de travail offre l'expérience la plus flexible et la plus intégrée pour l'authentification et l'autorisation. Il utilise le système d'identité de Google Cloudcomme source unique de vérité pour la gestion des autorisations. Choisissez cette option si vous souhaitez :
Gérez de manière 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.
Activez l'authentification des clients provenant d'autres clouds, comme AWS ou Azure, ou de fournisseurs d'identité sur site, comme Okta ou ADFS, à 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 concernant l'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 un aperçu 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 Managed Kafka (
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 client spécifique dépend du mécanisme SASL/OAUTHBEARER ou SASL/PLAIN que vous utilisez.
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. Configurez ensuite 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 d'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 nom d'utilisateur/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 est 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 l'autorisation. 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 de SASL
La méthode d'authentification SASL présente les limites suivantes :
L'authentification SASL est intrinsèquement liée aux comptes principaux IAM. Elle ne convient pas aux organisations qui nécessitent 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. Il 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 (AC) 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 client 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.Surveiller 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 comptes principaux mTLS à l'aide des LCA Kafka. Vous ne pouvez pas utiliser de 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 le service AC. Toutefois, vous pouvez intégrer une racine de confiance externe en créant une autorité de certification subordonnée dans CA Service qui est reliée à votre autorité de certification externe.
Vous pouvez configurer un cluster pour qu'il fasse confiance à un maximum de 10 pools d'autorité de certification.