mTLS-Authentifizierung konfigurieren

Sie können Ihren Managed Service for Apache Kafka-Cluster so konfigurieren, dass Kafka-Clients mit gegenseitigem TLS (mTLS) authentifiziert werden. Bei dieser Methode werden Clientzertifikate aus dem Certificate Authority Service (CA Service) als Grundlage für die Authentifizierung verwendet. Diese Option bietet eine Alternative zum standardmäßigen SASL-Mechanismus, bei dem IAM-Hauptkonten (Identity and Access Management) verwendet werden.

Wenn Sie mTLS verwenden, muss die Autorisierung mit Kafka-ACLs konfiguriert werden. Grundlegende Konzepte werden in den folgenden Dokumenten beschrieben:

Hinweise

Bevor Sie die mTLS-Authentifizierung konfigurieren, müssen Sie Folgendes tun:

  • Cluster-Voraussetzungen prüfen Prüfen Sie, ob Sie einen Managed Service for Apache Kafka-Cluster haben, der nach dem 24. Juni 2025 erstellt wurde. Nur diese Cluster unterstützen die mTLS-Authentifizierung. Mit dem Befehl gcloud managed-kafka clusters describe oder auf der Detailseite des Clusters in der Console können Sie das Erstellungsdatum Ihres Clusters aufrufen.

  • CA Service konfigurieren Richten Sie den CA-Dienst und die CA-Pools ein, die Sie zum Ausstellen von Clientzertifikaten verwenden möchten. Sie müssen Root- und untergeordnete Zertifikate in den CA-Pools erstellen.

    1. Erstellen Sie einen CA-Pool. Notieren Sie sich die ID des CA-Pools.

      Weitere Informationen zum Erstellen eines CA-Pools finden Sie unter CA-Pool erstellen.

    2. Erstellen und aktivieren Sie eine Stamm-CA für den Pool.

      Weitere Informationen zum Aktivieren einer Root-CA für den Pool finden Sie unter Root-CA erstellen.

    3. Erstellen und aktivieren Sie eine oder mehrere untergeordnete Zertifizierungsstellen. Wir empfehlen, zum Ausstellen von Clientzertifikaten eine untergeordnete CA zu verwenden, anstatt eine Stamm-CA direkt zu nutzen.

      Weitere Informationen zum Erstellen einer untergeordneten Zertifizierungsstelle finden Sie unter Untergeordnete Zertifizierungsstelle erstellen.

Erforderliche Rollen und Berechtigungen

Zum Konfigurieren von mTLS müssen Sie dafür sorgen, dass sowohl Sie (der Nutzer) als auch der Dienst-Agent für Managed Service for Apache Kafka die erforderlichen IAM-Berechtigungen haben. Das gilt unabhängig davon, ob Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren, um mTLS zu konfigurieren.

Nutzerberechtigungen

Wenn Sie einen Managed Service for Apache Kafka-Cluster für mTLS erstellen oder konfigurieren möchten, benötigen Sie Berechtigungen zum Erstellen oder Aktualisieren der Clusterressource. Bitten Sie dazu Ihren Administrator, Ihnen die Rolle Managed Kafka Cluster Editor (roles/managedkafka.clusterEditor) für das Projekt mit Ihrem Cluster zuzuweisen.

Diese vordefinierte Rolle enthält die Berechtigungen managedkafka.clusters.create und managedkafka.clusters.update. Mit diesen Berechtigungen können Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster ändern, um die für mTLS erforderliche CA Service-Poolkonfiguration hinzuzufügen.

Sie benötigen keine separaten Berechtigungen für die CA Service-Ressourcen, um mTLS für den Kafka-Cluster zu konfigurieren, sofern Sie den vollständigen Ressourcenpfad des CA-Pools haben. Wenn Sie CA-Pools in derGoogle Cloud -Konsole ansehen, erstellen oder verwalten möchten, benötigen Sie jedoch zusätzliche Rollen, die speziell für den CA-Dienst gelten, z. B. CA Service Admin (roles/privateca.admin) oder CA Service Operator (roles/privateca.operator).

Berechtigungen des Dienst-Agents

Damit die mTLS-Integration funktioniert, benötigt der Dienst-Agent für Managed Service for Apache Kafka die Berechtigung für den Zugriff auf den angegebenen CA-Pool. Der Dienst-Agent ist ein von Google verwaltetes Dienstkonto für Ihr Projekt.

Zusammenfassung der erforderlichen Berechtigungen

Erweitern Sie den folgenden Abschnitt, um die erforderlichen Berechtigungen anzuzeigen.

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Dienst-Agent Zugriff auf CA-Pools gewähren

Wenn sich Ihr CA Service-CA-Pool und Ihr Managed Service for Apache Kafka-Cluster in verschiedenen Google Cloud Projekten befinden, müssen Sie dem Dienst-Agent des Clusters die Berechtigung zum Zugriff auf den CA-Pool erteilen. Der Dienst-Agent für Managed Service for Apache Kafka heißt service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com.

Weisen Sie dem Managed Service for Apache Kafka-Dienst-Agent die Rolle CA Pool Reader (roles/privateca.poolReader) auf der Ebene des einzelnen Pools (empfohlen), der Ihre Zertifizierungsstellen enthält, oder für alle Pools im Projekt zu. Diese Rolle bietet die erforderliche Berechtigung privateca.caPools.get.

Individueller CA-Pool

Es wird empfohlen, Berechtigungen für einen einzelnen CA-Pool zu erteilen, da dies dem Prinzip der geringsten Berechtigung entspricht.

Führen Sie den Befehl gcloud privateca pools add-iam-policy-binding aus:

gcloud privateca pools add-iam-policy-binding CA_POOL_ID \
    --location=CA_POOL_LOCATION \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

Ersetzen Sie Folgendes:

  • CA_POOL_ID: Die ID des CA-Pools, für den Sie Zugriff gewähren. Beispiel: test-mtls-pool1.

  • CA_POOL_LOCATION: Die Google Cloud Region, in der sich der CA-Pool befindet. Beispiel: us-central1

  • CLUSTER_PROJECT_NUMBER: Die Projektnummer des Projekts, das Ihren Managed Service for Apache Kafka-Cluster enthält. Beispiel: 12341234123.

Alle CA-Pools

Alternativ können Sie dem Dienst-Agenten die Berechtigung zum Zugriff auf alle CA-Pools in einem Projekt erteilen, indem Sie die Richtlinie auf Projektebene festlegen.

Führen Sie den Befehl gcloud projects add-iam-policy-binding aus:

gcloud projects add-iam-policy-binding CA_PROJECT_ID \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

Ersetzen Sie Folgendes:

  • CA_PROJECT_ID: Die ID des Projekts, das die CA-Pools enthält, auf die Sie Zugriff gewähren. Beispiel: test-cas-project.

  • CLUSTER_PROJECT_NUMBER: Die Projektnummer des Projekts, das Ihren Managed Service for Apache Kafka-Cluster enthält. Beispiel: 12341234123.

mTLS auf einem Cluster aktivieren

Um mTLS zu aktivieren, geben Sie für Ihren Cluster die Ressourcennamen von einem oder mehreren CA-Pools des CA Service an, die für die Clientauthentifizierung verwendet werden sollen. Sie können dies tun, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren, der nach dem 24. Juni 2025 erstellt wurde.

Nachdem Sie die CA-Pool-IDs angegeben haben, lädt der Dienst die CA-Zertifikate automatisch aus den angegebenen Pools herunter und installiert sie im Truststore jedes Brokers im Cluster.

Console

Sie können mTLS beim Erstellen eines neuen Clusters oder für einen vorhandenen Cluster aktivieren, indem Sie ihn bearbeiten.

In einem neuen Cluster

  1. Rufen Sie in der Google Cloud Console die Seite Cluster auf.

    Zu den Clustern

  2. Wählen Sie Erstellen aus.

    Die Seite Kafka-Cluster erstellen wird geöffnet.

  3. Folgen Sie der Anleitung unter Cluster erstellen.
  4. Suchen Sie vor dem letzten Schritt nach dem Abschnitt Optionale mTLS-Konfiguration.
  5. Geben Sie den vollständigen Ressourcennamen eines Zertifizierungsstellenpools im Format projects/PROJECT_ID/LOCATION/LOCATION/caPools/POOL_ID ein.
  6. Wenn Sie weitere hinzufügen möchten, klicken Sie auf CA-Pool hinzufügen. Sie können bis zu 10 CA-Pools hinzufügen.
  7. Optional: Geben Sie Regeln für die Hauptkontozuordnung ein.
  8. Klicken Sie auf Erstellen, um den Cluster mit aktiviertem mTLS zu erstellen.

In einem vorhandenen Cluster

  1. Rufen Sie in der Google Cloud Console die Seite Cluster auf.

    Zu den Clustern

  2. Klicken Sie auf den Namen des Clusters, den Sie aktualisieren möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Fügen Sie im Abschnitt mTLS-Konfiguration die Liste der CA-Pools hinzu oder ändern Sie sie. Sie können bis zu 10 CA-Pools hinzufügen.
  5. Optional: Geben Sie Zuordnungsregeln für Principals ein oder bearbeiten Sie sie.
  6. Klicken Sie auf Speichern.

gcloud

In einem neuen Cluster

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Führen Sie den Befehl gcloud managed-kafka clusters create mit dem Flag --mtls-ca-pools aus. In diesem Beispiel sind zwei CA-Pools konfiguriert.

    gcloud managed-kafka clusters create CLUSTER_ID \
    --location=LOCATION \
    --cpu=3 \
    --memory=3GiB \
    --subnets=projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2

Ersetzen Sie Folgendes:

  • CLUSTER_ID: Die ID oder der Name des Clusters.

    Weitere Informationen zum Benennen eines Clusters finden Sie unter Richtlinien zum Benennen einer Managed Service for Apache Kafka-Ressource. Beispiel: test-mtls-cluster.

  • LOCATION: Der Standort des Clusters.

    Weitere Informationen zu unterstützten Standorten finden Sie unter Unterstützte Standorte für Managed Service for Apache Kafka. Beispiel: us-central1.

  • SUBNETS: Die Liste der Subnetze, die verbunden werden sollen. Trennen Sie mehrere Subnetzwerte durch Kommas.

    Das Format des Subnetzes ist projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID.

    • POOL_ID_1: die ID des ersten CA-Pools. Beispiel: test-mtls-pool1.

  • POOL_ID_2: die ID des zweiten CA-Pools. Beispiel: test-mtls-pool2.

In einem vorhandenen Cluster

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Führen Sie den Befehl gcloud managed-kafka clusters update aus. Mit diesem Befehl wird die gesamte derzeit konfigurierte Gruppe von Pools überschrieben. Geben Sie die vollständige Liste der erforderlichen CA-Pools an. In diesem Beispiel sind zwei CA-Pools konfiguriert.

    gcloud managed-kafka clusters update CLUSTER_ID \
    --location=LOCATION \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2

Ersetzen Sie Folgendes:

Prinzipalnamenzuordnung konfigurieren

Wenn sich ein Client mit mTLS authentifiziert, wird der Kafka-Principal standardmäßig aus dem Subject Distinguished Name (DN) des Zertifikats abgeleitet und hat das Format User:CN=...,OU=...,O=...,L=...,ST=...,C=.... Erstellen Sie Zuordnungsregeln, um den Subject DN des Zertifikats in einen Alias umzuwandeln, der in Kafka-ACLs einfacher zu verwenden ist. Weitere Informationen zum Formular für den Subject DN finden Sie in der Apache Kafka-Dokumentation unter Customizing SSL User Name.

Diese Transformationen werden durch die ssl.principal.mapping.rules-Kafka-Broker-Eigenschaft definiert, die reguläre Ausdrücke verwendet, um Teile des Zertifikatsubjekts zu extrahieren und neu zu formatieren.

Sie können beispielsweise eine Regel anwenden, um einen vollständigen Subject-DN in einen Alias zu transformieren:

  • DN des Zertifikatsubjekts: CN=order-processing-app,OU=marketing,O=company,C=US

  • Zuordnungsregel:RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT

  • Resultierender Kafka-Principal:order-processing-app

In dieser Beispielregel wird der Common Name (CN) aus dem Zertifikatsubjekt extrahiert und als Prinzipalname in Kafka verwendet.

So legen Sie mit der Google Cloud CLI eine Zuordnungsregel für Ihren Cluster fest: Wenn Sie die Console verwenden, können Sie die Zuordnungsregeln beim Erstellen oder Aktualisieren eines Clusters festlegen.

  • Verwenden Sie zum Aktualisieren Ihres Clusters den Befehl gcloud managed-kafka clusters update mit dem Flag --ssl-principal-mapping-rules.

    gcloud managed-kafka clusters update CLUSTER_ID \
    --location=REGION \
    --ssl-principal-mapping-rules='MAPPING_RULE'

    Ersetzen Sie Folgendes:

    • CLUSTER_ID: Die ID des Managed Service for Apache Kafka-Clusters, den Sie erstellen. Beispiel: test-kafka-cluster.

    • REGION: die Google Cloud Region, in der der Cluster erstellt werden soll. Beispiel: us-central1.

    • MAPPING_RULE*: Die Zuordnungsregel, die Sie anwenden möchten. Beispiel: RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT.

Weitere Informationen zum Schreiben von Zuordnungsregeln finden Sie in der Apache Kafka-Dokumentation unter Authorization and ACLs.

Kafka-ACLs für mTLS-Principals konfigurieren

Standardmäßig erhält jeder Client, der sich mit einem gültigen mTLS-Zertifikat authentifiziert, vollen Zugriff auf den Cluster. Um das Prinzip der geringsten Berechtigung durchzusetzen, müssen Sie Kafka-ACLs erstellen, um bestimmte Berechtigungen für Ihre mTLS-Principals zu definieren. Der Prinzipal für einen mTLS-Client ist der Subject-DN des Zertifikats (oder ein zugeordneter Alias), dem User: vorangestellt ist.

Zum Erstellen von Kafka-ACLs benötigen Sie die IAM-Rolle Managed Kafka ACL Editor (roles/managedkafka.aclEditor).

Angenommen, Sie haben eine Anwendung, die durch ihr Zertifikat identifiziert wird, Nachrichten für orders-topic erstellt und Nachrichten aus analytics-topic empfängt. Der Prinzipal der Anwendung ist nach der Vereinfachung mit einer Zuordnungsregel order-processing-app. Wenn Sie Kafka-ACLs erstellen, müssen Sie dem Prinzipal das Präfix User: voranstellen.

  1. Wenden Sie die ACL WRITE auf den Cluster an. Führen Sie den Befehl gcloud managed-kafka acls add-entry aus, um die Berechtigung WRITE für orders-topic zu erteilen.

    gcloud managed-kafka acls add-entry topic/orders-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host="*"

    Ersetzen Sie Folgendes:

    • CLUSTER_ID: Die ID des Managed Service for Apache Kafka-Clusters, den Sie erstellen. Beispiel: test-kafka-cluster.

    • REGION: die Google Cloud Region, in der der Cluster erstellt werden soll. Beispiel: us-central1.

  2. Wenden Sie die ACL READ auf den Cluster an. Führen Sie den Befehl gcloud managed-kafka acls add-entry aus, um die Berechtigung READ für analytics-topic zu erteilen.

    gcloud managed-kafka acls add-entry topic/analytics-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=READ \
    --permission-type=ALLOW \
    --host="*"

Nachdem Sie diese ACLs angewendet haben, hat der order-processing-app-Client nur die von Ihnen erteilten Berechtigungen. Weitere Informationen zum Erstellen von ACLs finden Sie unter Kafka-ACLs erstellen.

Kafka-Clients konfigurieren

Nachdem Sie mTLS für Ihren Cluster konfiguriert haben, müssen Sie Ihre Clientanwendungen für die Authentifizierung mit dieser Methode konfigurieren. Dazu müssen Sie ein Clientzertifikat erstellen und die Eigenschaften Ihres Clients so konfigurieren, dass es verwendet wird.

  1. Erstellen Sie ein Clientzertifikat auf Ihrem Clientcomputer und laden Sie es herunter. Führen Sie den Befehl gcloud privateca certificates create aus, um ein neues Zertifikat aus einem der CA-Pools auszustellen, die Sie für Ihren Cluster konfiguriert haben.

    Mit diesem Befehl werden das Zertifikat client-cert.pem und der zugehörige private Schlüssel client-key.pem in Ihre lokale Umgebung heruntergeladen.

    gcloud privateca certificates create CERTIFICATE_ID \
    --project=PROJECT_ID \
    --issuer-location=REGION \
    --issuer-pool=POOL_ID \
    --ca=CA_NAME \
    --generate-key \
    --dns-san="client.example.com" \
    --subject="CN=test-client-app" \
    --key-output-file=client-key.pem \
    --cert-output-file=client-cert.pem

    Ersetzen Sie Folgendes:

    • CERTIFICATE_ID: Ein eindeutiger Name für das Zertifikatobjekt. Beispiel: order-app-cert.

    • PROJECT_ID: die ID des Projekts, das den CA-Pool enthält. Beispiel: test-project-12345.

    • REGION: die Region, in der sich der CA-Pool befindet. Beispiel: us-central1.

    • POOL_ID: die ID des CA-Pools, aus dem das Zertifikat ausgestellt werden soll. Beispiel: test-mtls-pool1.

    • CA_NAME: der Name der Zertifizierungsstelle im Pool. Beispiel: test-sub-ca.

    • --dns-san="client.example.com": Der alternative DNS-Antragstellername. Sie können einen beliebigen Wert verwenden, der für Ihren Kunden relevant ist.

    • --subject="CN=test-client-app": die Subjekt-DN. Dieser Name wird als mTLS-Prinzipal verwendet, sofern Sie keine Regel für die Zuordnung von Prinzipalnamen konfiguriert haben.

  2. Sehen Sie sich das Clientzertifikat und den Zertifikatsubjekt an und prüfen Sie ssl.principal.mapping.rules. Führen Sie den Befehl gcloud privateca certificates describe aus:

    gcloud privateca certificates describe CERTIFICATE_ID \
   --issuer-pool=POOL_ID \
   --issuer-location=REGION

    Ersetzen Sie Folgendes:

    • CERTIFICATE_ID: Der eindeutige Name für das Zertifikatobjekt. Beispiel: order-app-cert.

    • POOL_ID: die ID des CA-Pools, aus dem Sie das Zertifikat ausgestellt haben. Beispiel: test-mtls-pool1.

    • REGION: die Region, in der sich der CA-Pool befindet. Beispiel: us-central1.

    Die Ausgabe sieht etwa so aus:

    certificateDescription:
  aiaIssuingCertificateUrls:
  - http://privateca-content-68e092f4-0000-288c-95cf-30fd3814648c.storage.googleapis.com/a6553d092bbedd752e34/ca.crt
  authorityKeyId:
    keyId: 9568aa9d2baa11a097addc2e24adeaebea0d6a2a
  certFingerprint:
    sha256Hash: 230e52b8411fd094048fca194fc6cf80e41b3e8561298aec3519e13cb1fd05eb
  ...
  subjectDescription:
    hexSerialNumber: 2107b74cf5a814043a38a87eeb6cd7c7891a5f
    lifetime: P30D
    notAfterTime: '2025-07-13T15:34:43Z'
    notBeforeTime: '2025-06-13T15:34:44Z'
    subject:
      commonName: test-client-app
    subjectAltName:
      dnsNames:
      - client.example.com
  ...

  3. Erstellen Sie einen Java KeyStore. Kombinieren Sie das Zertifikat und den privaten Schlüssel in einer PKCS#12-Datei und importieren Sie sie dann in eine Java KeyStore-Datei (.jks).

    # Create a password for the keystore
export KEYSTORE_PASSWORD="KEYSTORE_PASSWORD"

# Combine the key and cert into a PKCS#12 file
openssl pkcs12 -export -inkey client-key.pem -in client-cert.pem \
  -name client -out client-keystore.p12 -password "pass:$KEYSTORE_PASSWORD"

# Import the PKCS#12 file into a Java KeyStore
keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 \
  -destkeystore client-keystore.jks -srcstorepass "$KEYSTORE_PASSWORD" -deststorepass "$KEYSTORE_PASSWORD"

    Mit dem folgenden Befehl können Sie prüfen, ob der Schlüssel erfolgreich gespeichert wurde:

    keytool -v -list -keystore client-keystore.jks -storepass "$KEYSTORE_PASSWORD"

    Die Ausgabe sieht etwa so aus:

    Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: client
Creation date: Jun 13, 2024
Entry type: Private key entry
Certificate chain length: 1
Certificate[1]:
Owner: CN=test-client-app
Issuer: CN=test-sub-ca
...

    In der Zeile Owner wird der DN des Zertifikatsubjekts angezeigt. Standardmäßig legt Kafka den Kafka-Principal auf dieses genaue Format fest: CN=...,OU=...,O=...,L=...,ST=...,C=.... Weitere Informationen finden Sie in der Apache Kafka-Dokumentation unter Authorization and ACLs (Autorisierung und ACLs).

  4. Konfigurieren Sie die Kafka-Client-Attribute und die Bootstrap-Adresse. Legen Sie in Ihrer Kafka-Clientanwendung die folgenden Eigenschaften fest, um den Keystore für eine SSL-Verbindung zu verwenden. Achten Sie außerdem darauf, dass Sie die richtige Bootstrap-Adresse mit Port 9192 verwenden. Weitere Informationen zum Einrichten eines Clients finden Sie unter Schnellstart: Managed Service for Apache Kafka-Cluster erstellen und Client verbinden.

    security.protocol=SSL
ssl.keystore.location=KEYSTORE_LOCATION
ssl.keystore.password=KEYSTORE_PASSWORD
bootstrap.servers=CLUSTER_BOOTSTRAP_ADDRESS

    Ersetzen Sie Folgendes:

    • KEYSTORE_LOCATION: der Pfad zur Datei .jks.

    • KEYSTORE_PASSWORD: das Passwort für den Keystore.

    • CLUSTER_BOOTSTRAP_ADDRESS: Die Bootstrap-Adresse Ihres Clusters. Informationen zum Suchen der Bootstrap-Adresse finden Sie unter Clusterdetails ansehen. Geben Sie die Portnummer als 9192 an.

Clientkonfiguration schützen

Im vorherigen Beispiel werden private Schlüssel und Passwörter lokal gespeichert. Wir empfehlen dies daher nicht für Produktionsumgebungen. In der Produktion müssen Sie Ihre Client-Secrets sicher verwalten. Diese Optionen sind verfügbar:

  • Speichern Sie den Keystore und sein Passwort als Secrets in Google Cloud Secret Manager und rufen Sie sie zur Laufzeit in Ihrem Anwendungscode ab.

  • Wenn Sie Ihre Anwendung in GKE bereitstellen, verwenden Sie das Secret Manager-Add-on, um die Secrets zur Laufzeit in das Dateisystem Ihrer Anwendung einzubinden.

mTLS überwachen

Sie können den Zustand von mTLS-Zertifikatsupdates mithilfe von Messwerten und Logs in Cloud Monitoring und Cloud Logging überwachen.

Verwenden Sie den Messwert managedkafka.googleapis.com/mtls_truststore_update_count in Monitoring, um den Zustand von mTLS-Zertifikatsupdates proaktiv zu überwachen. Dieser Messwert zählt die Versuche, den Truststore zu aktualisieren, und enthält das Label STATUS, das SUCCESS oder ein Fehlergrund wie CA_POOL_FETCH_ERROR sein kann.

Der Managed Service for Apache Kafka versucht, den Truststore einmal pro Stunde für jeden Cluster zu aktualisieren. Wir empfehlen, eine Benachrichtigung zu erstellen, die ausgelöst wird, wenn für diesen Messwert über einen Zeitraum von mehr als drei Stunden eine konstante Anzahl von Fehlern gemeldet wird. Dies kann auf eine Fehlkonfiguration hinweisen, die manuell behoben werden muss.

Für Truststore-Aktualisierungen wird das Kontingent der Certificate Authority Service API verwendet. Wichtig:

  • Beim Aktualisieren wird die Methode FetchCaCerts aufgerufen, die dem Kontingent API requests per minute per region unterliegt.

  • Diese Kontingentnutzung wird Ihrem Projekt mit dem referenzierten Zertifizierungsstellenpool und nicht dem Managed Service for Apache Kafka-Projekt zugeordnet.

  • Das Standardlimit beträgt 400 Abfragen pro Sekunde (Queries per second, QPS) pro Region. Angesichts der geringen Häufigkeit von einer Anfrage pro Cluster pro Stunde ist es unwahrscheinlich, dass Sie dieses Kontingent durch diese Truststore-Aktualisierungen überschreiten.

Sie können Truststore-Updates auch nachverfolgen, indem Sie sich Logs in Logging ansehen. Suchen Sie nach den folgenden Logeinträgen, um zu prüfen, ob die Aktualisierungen erfolgreich waren:

  • Managed Service for Apache Kafka updated the mTLS trust store

  • Added root CA certificate to trust store

Nächste Schritte

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder deren Tochtergesellschaften in den USA und/oder anderen Ländern.