Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Konfiguration der Cluster-Authentifizierungsmethoden in Lambda Lambda unterstützt mehrere Methoden zur Authentifizierung mit Ihrem selbstverwalteten Apache-Kafka-Cluster. Stellen Sie sicher, dass Sie den Kafka-Cluster für die Verwendung einer der folgenden unterstützten Authentifizierungsmethoden konfigurieren. Weitere Informationen zur Sicherheit von Kafka finden Sie unter [Sicherheit](http://kafka.apache.org/documentation.html#security) in der Kafka-Dokumentation. ## SASL/SCRAM authentication Lambda unterstützt Simple Authentication and Security Layer/Salted Challenge-Response-Authentifizierungsmechanismus (SASL/SCRAM) Authentifizierung mit Transport Layer Security (TLS) -Verschlüsselung (`SASL_SSL`). Lambda sendet die verschlüsselten Anmeldeinformationen zur Authentifizierung mit dem Cluster. Lambda unterstützt nicht SASL/SCRAM mit Klartext (`SASL_PLAINTEXT`). Für weitere Informationen über SASL/SCRAM Authentifizierung finden Sie unter [RFC 5802](https://tools.ietf.org/html/rfc5802). Lambda unterstützt auch SASL/PLAIN Authentifizierung. Da dieser Mechanismus Anmeldeinformationen im Klartext verwendet, muss die Verbindung zum Server TLS-Verschlüsselung verwenden, um sicherzustellen, dass die Anmeldeinformationen geschützt sind. Für die SASL-Authentifizierung speichern Sie die Anmeldeinformationen als Secret in AWS Secrets Manager. Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter [Erstellen Sie eine AWS Secrets Manager Geheimnis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) in der *AWS Secrets Manager Benutzerleitfaden*. **Wichtig** Um Secrets Manager für die Authentifizierung zu verwenden, müssen Geheimnisse im selben gespeichert werden AWS Region als Ihre Lambda-Event-Funktion. ## Gegenseitige TLS-Authentifizierung Gegenseitige TLS (mTLS) bietet eine bidirektionale Authentifizierung zwischen Client und Server. Der Client sendet ein Zertifikat an den Server, damit der Server den Client überprüfen kann, und der Server sendet ein Zertifikat an den Client, damit der Client den Server überprüfen kann. Im selbstverwalteten Apache Kafka fungiert Lambda als Client. Sie konfigurieren ein Client-Zertifikat (als Secret in Secrets Manager), um Lambda für Ihre Kafka-Broker zu authentifizieren. Das Client-Zertifikat muss von einer Zertifizierungsstelle im Trust Store des Servers signiert sein. Der Kafka-Cluster sendet ein Serverzertifikat an Lambda, um die Kafka-Broker für Lambda zu authentifizieren. Das Serverzertifikat kann ein öffentliches oder ein privates CA-Zertifikat sein CA/self-signed Zertifikat. Das öffentliche CA-Zertifikat muss von einer Zertifizierungsstelle (CA) signiert sein, die sich im Trust Store von Lambda befindet. Für ein privates CA/self-signed Zertifikat, Sie konfigurieren das Server-Root-CA-Zertifikat (als geheimes Zertifikat in Secrets Manager). Lambda verwendet das Root-Zertifikat, um die Kafka-Broker zu verifizieren. Weitere Informationen über mTLS finden Sie unter [Vorstellung von gegenseitiger TLS-Authentifizierung für Amazon MSK als Ereignisquelle](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source). ## OAuth-2.0-Authentifizierung Lambda unterstützt SASL/OAUTHBEARER Authentifizierung mit TLS-Verschlüsselung (`SASL_SSL`). Lambda fordert ein Zugriffstoken von Ihrem OAuth 2.0-Identitätsanbieter an und übergibt dieses Token Ihren Kafka-Brokern. Lambda aktualisiert das Token, bevor es abläuft. Konfigurieren Sie Ihre Broker so, dass sie Token desselben Identitätsanbieters validieren. Um diese Methode zu verwenden, wählen Sie `OAUTHBEARER_AUTH` als `Type` von einem [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) und geben Sie den Secrets Manager-ARN Ihres OAuth-Geheimnisses im `URI` Feld. Den Inhalt des Geheimnisses finden Sie unter [Konfiguration des OAuth-Geheimnisses](#smaa-auth-oauth-secret). Lambda unterstützt zwei Arten von Zuschüssen. Die Felder, die Sie im Secret speichern, bestimmen, welches Lambda verwendet. + **Anmeldeinformationen des Kunden** — Lambda sendet eine Client-ID und ein Client-Geheimnis an den Token-Endpunkt. Verwenden Sie diesen Gewährungstyp, wenn Ihr Identitätsanbieter ein geheimes Client-Geheimnis ausstellt. + **JWT-Träger** — Lambda signiert eine JSON Web Token (JWT) -Assertion mit einem privaten Schlüssel und sendet die Assertion an den Token-Endpunkt. Verwenden Sie diesen Gewährungstyp, wenn Ihr Identitätsanbieter eine signierte Assertion anstelle eines geheimen Client-Schlüssels erwartet. Wenn Ihr Identitätsanbieter oder Ihre Broker zusätzliche Werte benötigen, geben Sie für jeden Wert einen eigenen Konfigurationseintrag für den Quellzugriff an. Geben Sie den Literalwert in das `URI` Feld statt eines geheimen ARN. + `OAUTHBEARER_SCOPE` — Der Bereich, den Lambda anfordert, wenn es nach einem Token fragt. + `OAUTHBEARER_AUDIENCE` — Die Zielgruppe, die Lambda anfordert, wenn es nach einem Token fragt. + `OAUTHBEARER_LOGICAL_CLUSTER` — Die logische Cluster-ID, die Lambda als SASL-Erweiterung an Ihre Broker sendet. + `OAUTHBEARER_IDENTITY_POOL` — Die Identitätspool-ID, die Lambda als SASL-Erweiterung an Ihre Broker sendet. **Anmerkung** Für diese vier Typen ist ein OAuth 2.0-Authentifizierungstyp erforderlich. Stellen Sie ihnen Folgendes zur Verfügung `OAUTHBEARER_AUTH`, oder nur bereitstellen `OAUTHBEARER_AUDIENCE` mit `IAM_OAUTHBEARER_AUTH`. Wenn Sie einen von ihnen ohne einen dieser Authentifizierungstypen angeben, gibt Lambda einen Validierungsfehler zurück. Wenn Ihre Broker ein von einer privaten Zertifizierungsstelle signiertes Zertifikat vorlegen, geben Sie außerdem Folgendes an `SERVER_ROOT_CA_CERTIFICATE` damit Lambda sie verifizieren kann. Weitere Informationen finden Sie unter [Konfigurieren des Secrets des Server-Root-CA-Zertifikats](#smaa-auth-ca-cert). ## IAM-Authentifizierung Wenn es sich bei Ihrem Cluster um einen Amazon MSK-Cluster handelt, den Sie über Ihr eigenes Netzwerk-Setup erreichen, können Sie ihn als selbstverwaltete Kafka-Ereignisquelle registrieren und sich bei IAM authentifizieren. Zu den benutzerdefinierten Netzwerk-Setups gehört ein benutzerdefinierter Domainname vor Ihren Brokern oder eine Verbindung von einem anderen Konto aus. Lambda signiert jede Verbindung mit den Anmeldeinformationen der Ausführungsrolle Ihrer Funktion, sodass Sie keine Anmeldeinformationen in Secrets Manager speichern. Um diese Methode zu verwenden, aktivieren Sie die IAM-Zugriffskontrolle auf Ihrem Cluster. Wählen Sie dann `IAM_AUTH` als der `Type` einer Quellzugriffskonfiguration und lassen Sie das weg `URI` Feld. Für die Ausführungsrolle Ihrer Funktion sind die Cluster-Berechtigungen erforderlich, die unter beschrieben sind [Konfigurieren von Rollenberechtigungen für Lambda-Ausführungen](with-kafka-permissions.md). Wenn Ihre Broker ein von einer privaten Zertifizierungsstelle signiertes Zertifikat vorlegen, geben Sie auch Folgendes an `SERVER_ROOT_CA_CERTIFICATE` damit Lambda sie verifizieren kann. Ein benutzerdefinierter Domainname vor Ihren Brokern benötigt dies normalerweise. ## IAM-Authentifizierung mit SASL/OAUTHBEARER Wenn Ihre Broker OAuth 2.0-Token akzeptieren, können Sie Folgendes verwenden AWS als Identitätsanbieter. Lambda präsentiert eine AWS Web-Identitätstoken für Ihre Broker über SASL/OAUTHBEARER. Lambda fordert ein kurzlebiges Token für die Ausführungsrolle Ihrer Funktion mit dem an `sts:GetWebIdentityToken` Aktion, sodass Sie keine Anmeldeinformationen in Secrets Manager speichern. Lambda fordert ein neues Token an, bevor das aktuelle abläuft. Um diese Methode zu verwenden, wählen Sie `IAM_OAUTHBEARER_AUTH` als `Type` einer Quellzugriffskonfiguration und lassen Sie das weg `URI` Feld. Sie müssen auch angeben `OAUTHBEARER_AUDIENCE` mit dem Publikum, das Ihre Makler erwarten. Die Ausführungsrolle Ihrer Funktion benötigt die Erlaubnis zum Aufrufen `sts:GetWebIdentityToken`. Konfigurieren Sie Ihre Broker so, dass sie vertrauen AWS als OpenID Connect (OIDC) -Identitätsanbieter, bevor Sie die Ereignisquellenzuordnung erstellen. Wenn Ihre Makler dem nicht vertrauen AWS Emittent, er lehnt das Token ab und Lambda kann nicht aus Ihren Themen lesen. **Anmerkung** `IAM_OAUTHBEARER_AUTH` unterstützt nur `OAUTHBEARER_AUDIENCE`. Wenn Sie auch angeben `OAUTHBEARER_SCOPE`, `OAUTHBEARER_LOGICAL_CLUSTER`, oder `OAUTHBEARER_IDENTITY_POOL`, Lambda gibt einen Validierungsfehler zurück. ## Konfigurieren des Client-Zertifikat-Secrets Das Secret CLIENT\_CERTIFICATE\_TLS\_AUTH erfordert ein Zertifikatfeld und ein Feld für einen privaten Schlüssel. Für einen verschlüsselten privaten Schlüssel erfordert das Secret ein Passwort für den privaten Schlüssel. Sowohl das Zertifikat als auch der private Schlüssel müssen im PEM-Format vorliegen. **Anmerkung** Lambda unterstützt die [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)-Algorithmen (aber nicht PBES2) zur Verschlüsselung von privaten Schlüsseln. Das Zertifikatfeld muss eine Liste von Zertifikaten enthalten, beginnend mit dem Client-Zertifikat, gefolgt von etwaigen Zwischenzertifikaten und endend mit dem Root-Zertifikat. Jedes Zertifikat muss in einer neuen Zeile mit der folgenden Struktur beginnen: ``` -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ``` Secrets Manager unterstützt Secrets von bis zu 65 536 Bytes, was genügend Platz für lange Zertifikatsketten bietet. Der private Schlüssel muss im Format [PKCS \#8](https://datatracker.ietf.org/doc/html/rfc5208) mit folgender Struktur vorliegen: ``` -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ``` Verwenden Sie für einen verschlüsselten privaten Schlüssel die folgende Struktur: ``` -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- ``` Im folgenden Beispiel sehen Sie den Inhalt eines Secrets für mTLS-Authentifizierung mit einem verschlüsselten privaten Schlüssel. Fügen Sie für einen verschlüsselten privaten Schlüssel das Passwort für den privaten Schlüssel in das Secret ein. ``` {"privateKeyPassword":"testpassword", "certificate":"-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey":"-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" } ``` ## Konfigurieren des Secrets des Server-Root-CA-Zertifikats Sie erstellen dieses Secret, wenn Ihre Kafka-Broker TLS-Verschlüsselung mit Zertifikaten verwenden, die von einer privaten CA signiert wurden. Sie können die TLS-Verschlüsselung für VPC verwenden, SASL/SCRAM, SASL/PLAIN, oder mTLS-Authentifizierung. Das Secret des Server-Root-CA-Zertifikats erfordert ein Feld, das das Root-CA-Zertifikat des Kafka-Brokers im PEM-Format enthält. Das folgende Beispiel zeigt die Struktur des Secrets. ``` {"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" } ``` ## Konfiguration des OAuth-Geheimnisses Sie erstellen dieses Geheimnis, wenn Sie es verwenden `OAUTHBEARER_AUTH`. Das Geheimnis ist ein JSON-Dokument. Jedes OAuth-Geheimnis benötigt `oauthTokenEndpointUrl` und `oauthClientId`. Fügen Sie die Felder für nur einen Zuschusstyp hinzu. Wenn Sie Felder aus beiden Zuschusstypen angeben, gibt Lambda einen Validierungsfehler zurück. | Feld | Erforderlich | Description | | --- | --- | --- | | `oauthTokenEndpointUrl` | Y | Der Token-Endpunkt Ihres Identitätsanbieters. Dies muss eine HTTPS-URL sein. | | `oauthClientId` | Y | Die Client-ID, die Ihr Identitätsanbieter ausgegeben hat. | | `oauthClientSecret` | Nur Kundenanmeldedaten | Das Client-Geheimnis, das Ihr Identitätsanbieter ausgegeben hat. | | `oauthClientEmail` | Nur JWT-Inhaber | Die Identität des Dienstkontos, die Lambda in die JWT-Assertion einfügt. | | `oauthPrivateKey` | Nur JWT-Inhaber | Der private Schlüssel, den Lambda zum Signieren der JWT-Assertion verwendet, im PEM-Format. | | `oauthTokenExpirationSeconds` | N | Die Lebensdauer der JWT-Assertion, die Lambda signiert. Gilt nur für den JWT-Bearer-Grant-Typ. | | `oauthIdpCaCertificate` | N | Das Root-CA-Zertifikat Ihres Identitätsanbieters im PEM-Format. Geben Sie dies an, wenn Ihr Identitätsanbieter ein von einer privaten CA signiertes Zertifikat vorlegt. | Das folgende Beispiel zeigt ein Geheimnis für den Gewährungstyp „Client-Anmeldeinformationen“. ``` {"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token", "oauthClientId":"my-client-id", "oauthClientSecret":"my-client-secret"} ``` Das folgende Beispiel zeigt ein Geheimnis für den JWT-Bearer-Grant-Typ. ``` {"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token", "oauthClientId":"my-client-id", "oauthClientEmail":"my-service-account@example.com", "oauthPrivateKey":"-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----"} ``` **Wichtig** Speichern Sie das Geheimnis in demselben AWS Region als Ihre Lambda-Funktion. Lambda liest das Geheimnis mit der Ausführungsrolle Ihrer Funktion, sodass diese Rolle Folgendes benötigt `secretsmanager:GetSecretValue` Erlaubnis für das Geheimnis. Sie können die Anmeldeinformationen im Secret rotieren, ohne die Zuordnung der Ereignisquelle neu erstellen zu müssen. Lambda nimmt die neuen Werte auf und fordert ein neues Token an.