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-Funktionen 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 werden Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) verwendet, um die mit der Umgebung verknüpfte Dienstkontoidentität automatisch zu finden. Dadurch müssen Sie keine statischen Anmeldedatendateien wie Dienstkontoschlüssel mehr verwalten und verteilen.
SASL/PLAIN: Diese Methode ist für die frühe Entwicklungsphase nützlich. Der Client authentifiziert sich mit einem langlebigen Dienstkontoschlüssel.
mTLS: Diese Option ist verfügbar, wenn die Standardauthentifizierung Ihrer Organisation auf Zertifikaten basiert. 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 der Sicherheitslage Ihrer Organisation und der vorhandenen Identitätsinfrastruktur 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, wodurch das Sicherheitsrisiko, das mit statischen Anmeldedateien verbunden ist, erheblich reduziert wird.
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 eines statischen Anmeldedatenpaars mit langer Lebensdauer auf der Clientseite erfordert.
Featurevergleich zwischen SASL und mTLS
Der primäre Authentifizierungsmechanismus für Managed Service for Apache Kafka ist SASL (Simple Authentication and Security Layer), das 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-Principals müssen mTLS-Principals 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 standardmäßig 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 mTLS-Authentifizierung mit Clientzertifikaten, die von Zertifizierungsstellen im CA Service ausgestellt wurden. Wenn Ihre Organisation einen externen Root of Trust verwendet, können Sie ihn integrieren, 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 | Name des Zertifikatsinhabers |
| Art der Qualifikation | 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 spezieller Anmeldehandler-Klasse (Java) oder lokalem Authentifizierungsserver (nicht Java) | JAAS-Konfiguration mit dem standardmäßigen PlainLoginModule (Java) | Schlüsselspeicher- und Truststore-Eigenschaften (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 über bekannteGoogle 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 mit 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 dann basierend auf dem ausgewählten SASL-Mechanismus konfigurieren. Im Folgenden finden Sie einen Überblick über den erforderlichen Workflow. Eine ausführliche 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 die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC). Die Konfiguration hängt von der Sprache des Kunden ab:
Java-Clients: Fügen Sie den Klassenpfad Ihrer Anwendung die spezielle Google Cloud Authentifizierungsbibliothek hinzu. Konfigurieren Sie dann die Kafka-Client-Properties so, dass die bereitgestellte
GcpLoginCallbackHandler-Klasse verwendet wird. Die Authentifizierung mit ADC wird dann automatisch durchgeführt.Die Klasse
GcpLoginCallbackHandlerwird mit dem OAUTHBEARER-Authentifizierungsmechanismus von Kafka verwendet, der speziell für die Verwendung mit Managed Service for Apache Kafka entwickelt wurde. Es übernimmt den Prozess des Abrufens eines JSON Web Tokens (JWT) vom Google-Identitätsanbieter, 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 sein, 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.
Indem Sie ein kurzlebiges Zugriffstoken abrufen.
Autorisierung konfigurieren Nachdem ein Client sich erfolgreich mit SASL authentifiziert hat, wird der Zugriff durch Berechtigungen gesteuert, die in IAM-Rollen oder Kafka-ACLs für den Cluster definiert sind.
SASL-Einschränkungen
Die SASL-Authentifizierungsmethode unterliegt den folgenden Einschränkungen:
Die SASL-Authentifizierung ist untrennbar mit IAM-Principals 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.
SASL verwendet keine Clientzertifikate für die Authentifizierung. 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 ausführliche 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. Wir empfehlen außerdem, die Broker-Eigenschaft
ssl.principal.mapping.rulesso zu konfigurieren, dass vereinfachte Prinzipalnamen für die Verwendung in ACLs erstellt werden. 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 Überwachen Sie nach der Einrichtung den Messwert
managedkafka.googleapis.com/mtls_truststore_update_count, um zu prüfen, ob die CA-Zertifikate des Clusters regelmäßig aus den CA-Service-Pools aktualisiert werden. Sie können auch Cloud Logging verwenden.
mTLS-Einschränkungen
Die mTLS-Funktion unterliegt den 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 Vertrauensbasis einbinden, indem Sie eine untergeordnete CA 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.