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
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
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 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
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 und geben Sie den Secrets Manager-ARN Ihres OAuth-Geheimnisses im URI Feld. Den Inhalt des Geheimnisses finden Sie unter Konfiguration des OAuth-Geheimnisses.
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.
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.
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
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----- <certificate contents> -----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
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Verwenden Sie für einen verschlüsselten privaten Schlüssel die folgende Struktur:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----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 |
|---|---|---|
|
Y |
Der Token-Endpunkt Ihres Identitätsanbieters. Dies muss eine HTTPS-URL sein. |
|
Y |
Die Client-ID, die Ihr Identitätsanbieter ausgegeben hat. |
|
Nur Kundenanmeldedaten |
Das Client-Geheimnis, das Ihr Identitätsanbieter ausgegeben hat. |
|
Nur JWT-Inhaber |
Die Identität des Dienstkontos, die Lambda in die JWT-Assertion einfügt. |
|
Nur JWT-Inhaber |
Der private Schlüssel, den Lambda zum Signieren der JWT-Assertion verwendet, im PEM-Format. |
|
N |
Die Lebensdauer der JWT-Assertion, die Lambda signiert. Gilt nur für den JWT-Bearer-Grant-Typ. |
|
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-----
<private key contents>
-----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.
