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 von selbstverwalteten Apache Kafka-Ereignisquellen für Lambda
Bevor Sie eine Ereignisquellenzuordnung für Ihren selbstverwalteten Apache Kafka-Cluster erstellen, müssen Sie sicherstellen, dass Ihr Cluster und der Cluster, in dem VPC er sich befindet, korrekt konfiguriert sind. Sie müssen auch sicherstellen, dass die Ausführungsrolle Ihrer Lambda-Funktion über die erforderlichen IAM Berechtigungen verfügt.
Folgen Sie den Anweisungen in den folgenden Abschnitten, um Ihren selbstverwalteten Apache Kafka-Cluster und die Lambda-Funktion zu konfigurieren. Informationen zum Erstellen der Ereignisquellenzuordnung finden Sie unter. Hinzufügen eines Kafka-Clusters als Ereignisquelle
Themen
Authentifizierung für Kafka-Cluster
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
VPCZugriff
Wenn nur Kafka-Benutzer in Ihrem Umfeld VPC auf Ihre Kafka-Broker zugreifen, müssen Sie die Kafka-Ereignisquelle für den Zugriff auf Amazon Virtual Private Cloud (AmazonVPC) konfigurieren.
SASL/Authentifizierung SCRAM
Lambda unterstützt die Authentifizierung Simple Authentication und Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) mit Transport Layer Security (TLS) -Verschlüsselung (). SASL_SSL Lambda sendet die verschlüsselten Anmeldeinformationen zur Authentifizierung mit dem Cluster. Lambda unterstütztSASL/SCRAMmit Klartext () SASL_PLAINTEXT nicht. Weitere Informationen zur SCRAM Authentifizierung mitSASL/finden Sie unter RFC 5802.
Lambda unterstützt auch die SASL PLAIN /-Authentifizierung. Da dieser Mechanismus Klartext-Anmeldeinformationen verwendet, muss die Verbindung zum Server TLS verschlüsselt werden, um sicherzustellen, dass die Anmeldeinformationen geschützt sind.
Für die SASL Authentifizierung speichern Sie die Anmeldedaten geheim in AWS Secrets Manager. Weitere Informationen zur Verwendung von Secrets Manager finden Sie im Tutorial: Erstellen und Abrufen eines Secrets im Benutzerhandbuch für AWS Secrets Manager .
Wichtig
Um Secrets Manager für die Authentifizierung zu verwenden, müssen Geheimnisse in derselben AWS Region wie Ihre Lambda-Funktion gespeichert werden.
Gegenseitige Authentifizierung TLS
Mutual TLS (mTLS) ermöglicht eine bidirektionale Authentifizierung zwischen dem Client und dem 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 CA-Zertifikat oder ein privates CA-Zertifikat/selbstsigniertes Zertifikat sein. Das öffentliche CA-Zertifikat muss von einer Zertifizierungsstelle (CA) signiert sein, die sich im Trust Store von Lambda befindet. Für ein privates CA-Zertifikat/selbstsigniertes Zertifikat konfigurieren Sie das Server-Root-CA-Zertifikat (als Secret in Secrets Manager). Lambda verwendet das Root-Zertifikat, um die Kafka-Broker zu verifizieren.
Weitere Informationen zu m TLS finden Sie unter Einführung der gegenseitigen TLS Authentifizierung für Amazon MSK als Ereignisquelle
Konfigurieren des Client-Zertifikat-Secrets
Das CLIENT _ _ CERTIFICATE TLS _ AUTH Secret erfordert ein Zertifikatsfeld 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 PEM ein Format haben.
Anmerkung
Lambda unterstützt die Verschlüsselungsalgorithmen mit privaten Schlüsseln 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 das 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-----
Das folgende Beispiel zeigt den Inhalt eines Geheimnisses für die TLS M-Authentifizierung unter Verwendung eines verschlüsselten privaten Schlüssels. 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 Geheimnis, wenn Ihre Kafka-Broker TLS Verschlüsselung mit Zertifikaten verwenden, die von einer privaten Zertifizierungsstelle signiert wurden. Sie können TLS Verschlüsselung für die TLS AuthentifizierungVPC,SASL/SCRAMPLAIN,SASL/oder m verwenden.
Das geheime Stammzertifikat der Server-Root-CA 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-----" }
Netzwerkkonfiguration
Damit Lambda Ihren Kafka-Cluster als Ereignisquelle verwenden kann, benötigt es Zugriff auf das Amazon, in dem sich VPC Ihr Cluster befindet. Wir empfehlen Ihnen, AWS PrivateLink VPCEndpunkte für Lambda bereitzustellen, um auf Ihre zuzugreifen. VPC Stellen Sie Endpunkte für Lambda und AWS Security Token Service ()AWS STS bereit. Wenn der Broker Authentifizierung verwendet, stellen Sie auch einen VPC Endpunkt für Secrets Manager bereit. Wenn Sie ein Ziel für den Fall eines Fehlers konfiguriert haben, stellen Sie auch einen VPC Endpunkt für den Zieldienst bereit.
Stellen Sie alternativ sicher, dass der mit Ihrem Kafka-Cluster VPC verknüpfte Cluster ein NAT Gateway pro öffentlichem Subnetz enthält. Weitere Informationen finden Sie unter Aktivieren Sie den Internetzugang für VPC verbundene Lambda-Funktionen.
Wenn Sie VPC Endpunkte verwenden, müssen Sie diese auch so konfigurieren, dass private Namen aktiviert werden. DNS
Wenn Sie eine Ereignisquellenzuordnung für einen selbstverwalteten Apache Kafka-Cluster erstellen, prüft Lambda, ob Elastic Network Interfaces (ENIs) bereits für die Subnetze und Sicherheitsgruppen Ihres Clusters vorhanden sind. VPC Wenn Lambda feststellt, dass sie vorhanden ENIs sind, versucht es, sie wiederzuverwenden. Andernfalls erstellt Lambda neue, ENIs um eine Verbindung zur Ereignisquelle herzustellen und Ihre Funktion aufzurufen.
Anmerkung
Lambda-Funktionen werden immer intern ausgeführt, die dem Lambda-Dienst VPCs gehören. Diese VPCs werden automatisch vom Dienst verwaltet und sind für Kunden nicht sichtbar. Sie können Ihre Funktion auch mit einem Amazon verbindenVPC. In beiden Fällen hat die VPC Konfiguration Ihrer Funktion keinen Einfluss auf die Zuordnung der Ereignisquelle. Nur die Konfiguration der Ereignisquellen VPC bestimmt, wie Lambda eine Verbindung zu Ihrer Ereignisquelle herstellt.
Weitere Informationen zur Konfiguration des Netzwerks finden Sie im AWS Compute-Blog unter Einrichtung AWS Lambda eines Apache Kafka-Clusters innerhalb eines VPC
VPCRegeln für Sicherheitsgruppen
Konfigurieren Sie die Sicherheitsgruppen für das AmazonVPC, das Ihren Cluster enthält, mit den folgenden Regeln (mindestens):
-
Regeln für eingehenden Datenverkehr – Lassen den gesamten Datenverkehr zum Port des Kafka-Brokers für die Sicherheitsgruppen zu, die für Ihre Ereignisquelle angegeben sind. Kafka verwendet standardmäßig Port 9092.
-
Ausgehende Regeln - Erlauben Sie allen Datenverkehr auf Port 443 für alle Ziele. Lassen den gesamten Datenverkehr zum Port des Kafka-Brokers für die Sicherheitsgruppen zu, die für Ihre Ereignisquelle angegeben sind. Kafka verwendet standardmäßig Port 9092.
-
Wenn Sie VPC Endpunkte anstelle eines NAT Gateways verwenden, müssen die den VPC Endpunkten zugewiesenen Sicherheitsgruppen den gesamten eingehenden Datenverkehr über Port 443 aus den Sicherheitsgruppen der Ereignisquelle zulassen.
Arbeiten mit VPC-Endpunkten
Wenn Sie VPC Endpunkte verwenden, werden API Aufrufe zum Aufrufen Ihrer Funktion mithilfe von über diese Endpunkte weitergeleitet. ENIs Der Lambda-Serviceprinzipal muss alle Rollen sts:AssumeRole und lambda:InvokeFunction Funktionen aufrufen und aktivieren, die diese ENIs verwenden.
Standardmäßig haben VPC Endpoints offene IAM Richtlinien. Es hat sich bewährt, diese Richtlinien so einzuschränken, dass nur bestimmte Prinzipale die erforderlichen Aktionen über diesen Endpunkt ausführen können. Um sicherzustellen, dass Ihre Ereignisquellenzuordnung Ihre Lambda-Funktion aufrufen kann, muss die VPC Endpunktrichtlinie zulassen, dass das Lambda-Serviceprinzip und aufruft. sts:AssumeRole lambda:InvokeFunction Wenn Sie Ihre VPC Endpunktrichtlinien so einschränken, dass sie nur API Anrufe zulassen, die ihren Ursprung in Ihrer Organisation haben, verhindert, dass die Zuordnung der Ereignisquellen ordnungsgemäß funktioniert.
Die folgenden VPC Beispiel-Endpunktrichtlinien zeigen, wie der erforderliche Zugriff auf den Lambda-Serviceprinzipal für die AWS STS und Lambda-Endpunkte gewährt wird.
Beispiel VPCEndpunktrichtlinie — Endpunkt AWS STS
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Beispiel VPCEndpunktrichtlinie — Lambda-Endpunkt
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Wenn Ihr Kafka-Broker Authentifizierung verwendet, können Sie auch die VPC Endpunktrichtlinie für den Secrets Manager Manager-Endpunkt einschränken. Um den Secrets Manager aufzurufenAPI, verwendet Lambda Ihre Funktionsrolle, nicht den Lambda-Serviceprinzipal. Das folgende Beispiel zeigt eine Secrets Manager Manager-Endpunktrichtlinie.
Beispiel VPCEndpunktrichtlinie — Secrets Manager Manager-Endpunkt
{ "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "customer_function_execution_role_arn" ] }, "Resource": "customer_secret_arn" } ] }
Wenn Sie ein Ziel für den Fall eines Fehlers konfiguriert haben, verwendet Lambda auch die Rolle Ihrer Funktion, um entweder s3:PutObjectsns:Publish, oder sqs:sendMessage mithilfe des von Lambda verwalteten Systems aufzurufen. ENIs
APIZugriffs- und Lambda-Funktionsberechtigungen
Zusätzlich zum Zugriff auf Ihren selbstverwalteten Kafka-Cluster benötigt Ihre Lambda-Funktion Berechtigungen, um verschiedene Aktionen auszuführen. API Sie fügen diese Berechtigungen zur Ausführungsrolle der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf API Aktionen benötigen, fügen Sie der Identitätsrichtlinie für den Benutzer oder die Rolle AWS Identity and Access Management (IAM) die erforderlichen Berechtigungen hinzu.
Benötigte Lambda-Funktionsberechtigungen
Um Protokolle in einer Protokollgruppe in Amazon CloudWatch Logs zu erstellen und zu speichern, muss Ihre Lambda-Funktion in ihrer Ausführungsrolle über die folgenden Berechtigungen verfügen:
Optionale Lambda-Funktionsberechtigungen
Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes:
-
Beschreiben Ihres Secrets-Manager-Secrets
-
Greifen Sie auf Ihren AWS Key Management Service (AWS KMS) vom Kunden verwalteten Schlüssel zu.
-
Greifen Sie auf Ihr Amazon zuVPC.
-
Senden von Datensätzen zu fehlgeschlagenen Aufrufen an ein Ziel
Secrets Manager und AWS KMS Berechtigungen
Abhängig von der Art der Zugriffskontrolle, die Sie für Ihre Kafka-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Erlaubnis, auf Ihr Secrets Manager-Geheimnis zuzugreifen oder Ihren vom AWS KMS Kunden verwalteten Schlüssel zu entschlüsseln. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen:
VPCBerechtigungen
Wenn nur Benutzer innerhalb eines auf Ihren selbstverwalteten Apache Kafka-Cluster zugreifen VPC können, muss Ihre Lambda-Funktion über die Berechtigung verfügen, auf Ihre Amazon-Ressourcen zuzugreifen. VPC Zu diesen Ressourcen gehören IhreVPC, Subnetze, Sicherheitsgruppen und Netzwerkschnittstellen. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen:
Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle
Standardmäßig ist es Lambda nicht gestattet, die erforderlichen oder optionalen Aktionen für einen selbstverwalteten Apache-Kafka-Cluster durchzuführen. Sie müssen diese Aktionen in einer IAMVertrauensrichtlinie für Ihre Ausführungsrolle erstellen und definieren. Dieses Beispiel zeigt, wie Sie eine Richtlinie erstellen könnten, die Lambda den Zugriff auf Ihre VPC Amazon-Ressourcen ermöglicht.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] }
Benutzern Zugriff mit einer IAM Richtlinie gewähren
Standardmäßig sind Benutzer und Rollen nicht berechtigt, APIVorgänge mit der Ereignisquelle auszuführen. Um Benutzern in Ihrem Unternehmen oder Ihrem Konto Zugriff zu gewähren, erstellen oder aktualisieren Sie eine identitätsbasierte Richtlinie. Weitere Informationen finden Sie im IAMBenutzerhandbuch unter Steuern des Zugriffs auf AWS Ressourcen mithilfe von Richtlinien.
