Auf dieser Seite werden die unterstützten Authentifizierungsmethoden für Clientanwendungen beschrieben, die eine Verbindung zu Google Cloud Managed Service for Apache Kafka-Brokern herstellen.
Für Google Cloud Managed Service for Apache Kafka-Clientanwendungen, die in Google Cloud -Diensten wie Google Kubernetes Engine, Compute Engine, Cloud Run oder Cloud Run Functions ausgeführt werden, haben Sie die folgenden Authentifizierungsoptionen:
SASL/OAUTHBEARER (empfohlen): Dies ist die nahtloseste und sicherste Methode für Clients in Google Cloud. Es verwendet Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um die mit der Umgebung verknüpfte Dienstkontoidentität automatisch zu finden. Dadurch müssen keine statischen Anmeldedatendateien wie Dienstkontoschlüssel mehr verwaltet und verteilt werden.
SASL/PLAIN: Diese Methode ist für die frühe Entwicklungsphase nützlich. Der Client authentifiziert sich mit einem Dienstkontoschlüssel mit langer Lebensdauer.
mTLS: Diese Option ist verfügbar, wenn der Standard Ihrer Organisation die zertifikatbasierte Authentifizierung ist. Ihre Anwendung auf Google Cloud ist mit einem Clientzertifikat und einem Schlüssel konfiguriert.
Für Clientanwendungen, die außerhalb von Google Cloudausgeführt werden, z. B. in einem lokalen Rechenzentrum oder bei einem anderen Cloud-Anbieter, sollten Sie die folgenden Authentifizierungsmethoden in Betracht ziehen. Wählen Sie die beste Methode basierend auf dem Sicherheitsstatus und der vorhandenen Identitätsinfrastruktur Ihrer Organisation aus.
Workload Identity-Föderation mit SASL/OAUTHBEARER (empfohlen): Dies ist die sicherste Methode für externe Clients. Damit können Sie Identitäten aus externen Systemen wie AWS, Microsoft Azure oder einem lokalen Identitätsanbieter wie ADFS die Möglichkeit geben, die Identität einesGoogle Cloud -Dienstkontos zu übernehmen. Anstatt langlebige Dienstkontoschlüssel zu verwalten, verwendet der Client seine bevorzugten Anmeldedaten, um ein kurzlebiges Google Cloud Zugriffstoken abzurufen. Der Client verwendet dieses Token dann zur Authentifizierung, was das Sicherheitsrisiko, das mit statischen Anmeldedateien verbunden ist, erheblich reduziert.
mTLS: Diese Methode ist anbieterunabhängig und eignet sich gut, wenn Ihre Organisation bereits eine Public-Key-Infrastruktur (PKI) zur Verwaltung von TLS-Zertifikaten für die Dienstidentität verwendet. Dadurch können sich Clients ohne eine Google Cloud-spezifische Identität authentifizieren. Ähnlich wie bei der Verwendung von Dienstkontoschlüsseln müssen Sie jedoch den Lebenszyklus und die Verteilung von langlebigen Anmeldedaten wie Clientzertifikaten verwalten.
SASL/PLAIN mit einem Dienstkontoschlüssel: Diese Methode bietet einem externen Client eine direkte Möglichkeit, sich als Google Cloud -Identität zu authentifizieren. Sie laden eine JSON-Datei mit dem Dienstkontoschlüssel herunter und verwenden sie in der SASL/PLAIN-Konfiguration Ihres Clients. Diese Methode wird für Produktionsarbeitslasten im Allgemeinen nicht empfohlen, da sie die Verwaltung und Sicherung einer langlebigen statischen Anmeldedaten auf der Clientseite erfordert.
Funktionsvergleich zwischen SASL und mTLS
Der primäre Authentifizierungsmechanismus für Managed Service for Apache Kafka ist SASL (Simple Authentication and Security Layer), der direkt in die Identitätsdienste vonGoogle Cloudeingebunden ist. SASL authentifiziert Clients standardmäßig mit einem Google Cloud IAM-Hauptkonto, z. B. einem Dienstkonto. Für die Autorisierung bietet SASL Flexibilität: Sie können den Zugriff auf Cluster mit detaillierten IAM-Rollen und den Access Control Lists (ACLs) von Kafka verwalten.
Im Gegensatz dazu bietet mTLS eine anbieterunabhängige Authentifizierungsmethode, die nicht auf Google Cloud IAM basiert. Stattdessen wird ein Client bei mTLS anhand seines TLS-Zertifikats authentifiziert. Die Identität wird aus dem Betreffnamen des Zertifikats abgeleitet.
Dieser Unterschied führt zu einem wichtigen Unterschied bei der Autorisierung. Im Gegensatz zu SASL-Hauptkonten müssen mTLS-Hauptkonten ausschließlich mit Kafka-ACLs autorisiert werden. Sie können nicht mit Google Cloud IAM-Rollen verwaltet werden.
Wir empfehlen dringend, Kafka-ACLs für Ihren Cluster zu konfigurieren. Wenn keine ACLs festgelegt sind, wird durch das standardmäßige Kafka-Verhalten allen authentifizierten Principals – unabhängig davon, ob SASL oder mTLS verwendet wird – vollständiger Zugriff auf den Cluster gewährt. Weitere Informationen zum Konfigurieren von Kafka-ACLs finden Sie unter Managed Service for Apache Kafka-ACL erstellen.
Managed Service for Apache Kafka unterstützt die gegenseitige TLS-Authentifizierung (mTLS) mit Clientzertifikaten, die von Zertifizierungsstellen im CA Service ausgestellt wurden. Wenn Ihre Organisation eine externe Root of Trust verwendet, können Sie sie einbinden, indem Sie eine untergeordnete Zertifizierungsstelle in CA Service erstellen, die mit Ihrer externen Zertifizierungsstelle verkettet ist.
In der folgenden Tabelle werden die Funktionen der Authentifizierungsmethoden verglichen.
| Funktion | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| Primäre Identität | Google Cloud IAM-Prinzipal | Google Cloud IAM-Prinzipal | Antragstellername des Zertifikats |
| Art des Berechtigungsnachweises | Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) oder OAuth 2.0-Token | Base64-codierter Dienstkontoschlüssel | Clientzertifikat und privater Schlüssel |
| Autorisierungsmethode | Google Cloud IAM-Rollen oder Kafka-ACLs | Google Cloud IAM-Rollen oder Kafka-ACLs | Nur Kafka-ACLs |
| Anwendungsfall | Clients auf Google Cloud; externe Clients mit Workload Identity-Föderation | Einfache Clients, Testszenarien oder Legacy-Systeme, in denen ein Dienstkontoschlüssel erforderlich ist. | Anbieterunabhängig; ideal für lokale, Multi-Cloud- oder bestehende PKI-Anwendungen. |
| Clientkonfiguration | JAAS-Konfiguration mit einer speziellen Anmeldehandler-Klasse (Java) oder einem lokalen Authentifizierungsserver (nicht Java) | JAAS-Konfiguration mit dem Standard-PlainLoginModule (Java) | Keystore- und Truststore-Properties (z. B. security.protocol=SSL) |
| Clusterverfügbarkeit | Alle Cluster | Alle Cluster | Nach dem 24. Juni 2025 erstellte Cluster |
SASL oder mTLS auswählen
Die Wahl der Authentifizierungsmethode richtet sich nach den Sicherheitsrichtlinien und der vorhandenen Infrastruktur Ihrer Organisation. Für die meisten Anwendungsfälle empfehlen wir die Verwendung von SASL mit Google Cloud IAM.
SASL mit Google Cloud IAM oder Workload Identity-Föderation bietet die flexibelste und integrierteste Lösung für die Authentifizierung und Autorisierung. Dabei wird das Identitätssystem von Google Cloudals zentrale Informationsquelle für die Verwaltung von Berechtigungen verwendet. Wählen Sie diesen Pfad aus, wenn Sie Folgendes tun möchten:
Berechtigungen für Ihre Kafka-Clients lassen sich zentral mit den bekanntenGoogle Cloud IAM-Rollen verwalten.
Vermeiden Sie die Verwaltung statischer Anmeldedaten auf Clients.
Aktivieren Sie die Authentifizierung von Clients aus anderen Clouds wie AWS, Azure oder lokalen Identitätsanbietern wie Okta oder ADFS mithilfe der Workload Identity-Föderation. Diese Methode bietet eine sichere, cloudunabhängige Identitätslösung, ohne dass Sie zu einem anderen Authentifizierungsprotokoll wechseln müssen.
Wählen Sie mTLS aus, wenn Ihre Organisation strenge Anforderungen an die zertifikatbasierte Authentifizierung hat. Dies ist erforderlich, wenn Sie eine vorhandene lokale Kafka-Bereitstellung migrieren, in der bereits TLS-Zertifikate für die Identität verwendet werden, oder wenn Unternehmensrichtlinien Clientzertifikate für alle Anwendungen vorschreiben. mTLS bietet zwar eine starke Sicherheit auf Transportebene, aber die Autorisierung für mTLS-Clients muss ausschließlich mit Kafka-ACLs verwaltet werden, die von Google Cloud IAM getrennt sind.
Workflow zum Konfigurieren von SASL/PLAIN oder SASL/OAUTHBEARER
Wenn Sie einen Client für die Verwendung der SASL-Authentifizierung mit Managed Service for Apache Kafka konfigurieren, müssen Sie der Identität des Clients Berechtigungen erteilen und die Clientanwendung basierend auf dem ausgewählten SASL-Mechanismus konfigurieren. Im Folgenden finden Sie eine Übersicht über den erforderlichen Workflow. Eine detaillierte Anleitung zum Konfigurieren von SASL finden Sie unter SASL-Authentifizierung konfigurieren.
IAM-Berechtigungen erteilen Sie müssen dem Dienstkonto, das Ihr Client zur Authentifizierung verwendet, zuerst die Rolle Managed Kafka Client (
roles/managedkafka.client) zuweisen. Diese Rolle bietet die erforderliche Berechtigungmanagedkafka.clusters.connect, um eine Verbindung zu Kafka-Clustern im Projekt herzustellen.Kafka-Client konfigurieren Die spezifische Clientkonfiguration hängt davon ab, ob Sie den SASL/OAUTHBEARER- oder den SASL/PLAIN-Mechanismus verwenden.
Für SASL/OAUTHBEARER (empfohlen): Dieser Mechanismus verwendet ADC (Application Default Credentials). Die Konfiguration hängt von der Sprache Ihres Kunden ab:
Java-Clients: Fügen Sie den Klassenpfad Ihrer Anwendung die spezielle Google Cloud Authentifizierungsbibliothek hinzu. Konfigurieren Sie dann die Kafka-Client-Eigenschaften so, dass die bereitgestellte
GcpLoginCallbackHandler-Klasse verwendet wird. Diese übernimmt die Authentifizierung mit ADC automatisch.Die Klasse
GcpLoginCallbackHandlerwird mit dem OAUTHBEARER-Authentifizierungsmechanismus von Kafka verwendet und ist speziell für die Verwendung mit Managed Service for Apache Kafka konzipiert. Es übernimmt den Prozess des Abrufens eines JSON Web Token (JWT) vom Identitätsanbieter von Google, sodass sich Kafka-Clients mit dem Dienst über ADC authentifizieren können.Nicht-Java-Clients: Führen Sie einen bereitgestellten lokalen Authentifizierungsserver auf dem Clientcomputer aus. Dieser Server verwendet ADC, um Anmeldedaten abzurufen und dem Kafka-Client zur Verfügung zu stellen. Der Client wird dann so konfiguriert, dass er sein Authentifizierungstoken vom Endpunkt dieses lokalen Servers abruft.
Für SASL/PLAIN
Bei diesem Mechanismus wird eine Kombination aus Nutzername und Passwort verwendet. Die Clientanwendung muss für die Verwendung des SASL_SSL-Sicherheitsprotokolls, des PLAIN-Mechanismus und einer JAAS-Konfiguration konfiguriert werden, in der die Klasse
PlainLoginModuleangegeben ist.Der Nutzername ist die E‑Mail-Adresse des Dienstkontos. Das Passwort kann auf zwei Arten generiert werden:
Durch Base64-Codierung einer JSON-Datei mit einem Dienstkontoschlüssel.
Sie rufen ein kurzlebiges Zugriffstoken ab.
Autorisierung konfigurieren Nachdem ein Client die Authentifizierung mit SASL erfolgreich abgeschlossen hat, wird der Zugriff durch Berechtigungen gesteuert, die in IAM-Rollen oder Kafka-ACLs für den Cluster definiert sind.
SASL-Einschränkungen
Für die SASL-Authentifizierungsmethode gelten die folgenden Einschränkungen:
Die SASL-Authentifizierung ist untrennbar mit IAM-Hauptkonten verbunden. Sie ist nicht für Organisationen geeignet, die eine strikte Trennung vonGoogle Cloud -Identitäten erfordern oder Nicht-Google-Identitäten verwenden, es sei denn, Sie konfigurieren die Identitätsföderation von Arbeitslasten.
Bei SASL werden keine Clientzertifikate für die Authentifizierung verwendet. Es ist nicht direkt für Organisationen geeignet, die zur Identifizierung von Anwendungen auf eine vorhandene PKI angewiesen sind.
Workflow für die Konfiguration von mTLS
Zum Konfigurieren von mTLS für Managed Service for Apache Kafka müssen Sie Zertifizierungsstellen, den Kafka-Cluster und Ihre Kafka-Clients konfigurieren. Eine detaillierte Anleitung zum Konfigurieren von mTLS finden Sie unter mTLS-Authentifizierung konfigurieren.
Zertifizierungsstellen konfigurieren Sie müssen zuerst CA-Pools in Certificate Authority Service (CA Service) erstellen und konfigurieren. Wenn Sie CA-Pools in einem anderen Projekt erstellen, müssen Sie dem Dienst-Agent für Managed Service for Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) die Berechtigung für den Zugriff auf diese Pools gewähren. Sie müssen Stamm- und untergeordnete Zertifikate in den CA-Pools erstellen.Kafka-Cluster konfigurieren Erstellen oder aktualisieren Sie Ihren Cluster, um mTLS zu aktivieren, indem Sie die Ressourcen-IDs Ihrer konfigurierten CA-Pools angeben. Außerdem haben wir empfohlen, die Broker-Property
ssl.principal.mapping.ruleszu konfigurieren, um vereinfachte Prinzipalnamen für die Verwendung in ACLs zu erstellen. Dazu können Sie Google Cloud CLI-Befehle verwenden.Kafka-Clients konfigurieren Rufen Sie Clientzertifikate von Ihren Zertifizierungsstellen ab und installieren Sie sie in der Umgebung Ihres Clients, z. B. in einem Java-Schlüsselspeicher. Die Clientanwendung muss dann mit dem richtigen Sicherheitsprotokoll (SSL) und dem Speicherort des Keystores konfiguriert werden, um eine Verbindung zum dedizierten mTLS-Bootstrap-Port des Clusters herzustellen, der
9192ist.mTLS überwachen Behalten Sie nach der Einrichtung den Messwert
managedkafka.googleapis.com/mtls_truststore_update_countim Blick, um zu prüfen, ob der Cluster seine CA-Zertifikate regelmäßig aus den CA-Service-Pools aktualisiert. Sie können auch Cloud Logging verwenden.
Einschränkungen von mTLS
Für die Funktion „mTLS“ gelten die folgenden Einschränkungen:
Sie können die mTLS-Funktion nur für Managed Service for Apache Kafka-Cluster verwenden, die nach dem 24. Juni 2025 erstellt wurden.
Sie müssen die Autorisierung für mTLS-Principals mit Kafka-ACLs konfigurieren. Sie können keine IAM-Rollenbindungen verwenden, um mTLS-Clients zu autorisieren.
Der Dienst authentifiziert nur Clients, die von CA Service verwaltete Zertifikate präsentieren. Sie können jedoch eine externe Root of Trust einbinden, indem Sie eine untergeordnete Zertifizierungsstelle in CA Service erstellen, die mit Ihrer externen CA verkettet ist.
Sie können einen Cluster so konfigurieren, dass er maximal 10 CA-Pools vertraut.