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 MSK Amazon-Ereignisquellen für Lambda
Bevor Sie eine Ereignisquellenzuordnung für Ihren MSK Amazon-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 MSK Amazon-Cluster und Ihre Lambda-Funktion zu konfigurieren. VPC Informationen zum Erstellen der Ereignisquellenzuordnung finden Sie unterAmazon MSK als Eventquelle hinzufügen.
Themen
MSKCluster-Authentifizierung
Lambda benötigt die Erlaubnis, auf den MSK Amazon-Cluster zuzugreifen, Datensätze abzurufen und andere Aufgaben auszuführen. Amazon MSK unterstützt mehrere Optionen zur Steuerung des Client-Zugriffs auf den MSK Cluster.
Cluster-Zugriffsoptionen
Nicht authentifizierter Zugriff
Wenn keine Clients über das Internet auf den Cluster zugreifen, können Sie einen nicht authentifizierten Zugriff verwenden.
SASL/SCRAMAuthentifizierung
Amazon MSK unterstützt die Authentifizierung Simple Authentication und Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) mit Transport Layer Security (TLS) -Verschlüsselung. Damit Lambda eine Verbindung zum Cluster herstellen kann, speichern Sie die Authentifizierungsdaten (Benutzername und Passwort) AWS Secrets Manager geheim.
Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter Benutzername und Passwortauthentifizierung mit AWS Secrets Manager im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.
Amazon unterstützt MSK keine SASL PLAIN /Authentifizierung.
Auf IAM-Rolle basierende Authentifizierung
Sie können IAM es verwenden, um die Identität von Clients zu authentifizieren, die eine Verbindung zum MSK Cluster herstellen. Wenn IAM Auth in Ihrem MSK Cluster aktiv ist und Sie kein Geheimnis für Auth angeben, verwendet Lambda automatisch standardmäßig Auth. IAM Verwenden Sie die Konsole oder, um benutzer- oder rollenbasierte Richtlinien zu erstellen und bereitzustellen. IAM API Weitere Informationen finden Sie unter IAMZugriffskontrolle im Amazon Managed Streaming for Apache Kafka Developer Guide.
Damit Lambda eine Verbindung zum MSK Cluster herstellen, Datensätze lesen und andere erforderliche Aktionen ausführen kann, fügen Sie der Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen hinzu.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:DescribeGroup", "kafka-cluster:AlterGroup", "kafka-cluster:DescribeTopic", "kafka-cluster:ReadData", "kafka-cluster:DescribeClusterDynamicConfiguration" ], "Resource": [ "arn:aws:kafka:
region
:account-id
:cluster/cluster-name
/cluster-uuid
", "arn:aws:kafka:region
:account-id
:topic/cluster-name
/cluster-uuid
/topic-name
", "arn:aws:kafka:region
:account-id
:group/cluster-name
/cluster-uuid
/consumer-group-id
" ] } ] }
Sie können diese Berechtigungen für einen bestimmten Cluster, ein bestimmtes Thema und eine bestimmte Gruppe einteilen. Weitere Informationen finden Sie in den Amazon MSK Kafka-Aktionen im Amazon Managed Streaming for Apache Kafka Developer Guide.
Gegenseitige Authentifizierung TLS
Mutual TLS (mTLS) ermöglicht 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.
Für Amazon MSK fungiert Lambda als Client. Sie konfigurieren ein Client-Zertifikat (als Secret in Secrets Manager), um Lambda bei den Brokern in Ihrem MSK Cluster zu authentifizieren. Das Client-Zertifikat muss von einer Zertifizierungsstelle im Trust Store des Servers signiert sein. Der MSK Cluster sendet ein Serverzertifikat an Lambda, um die Broker bei Lambda zu authentifizieren. Das Serverzertifikat muss von einer Zertifizierungsstelle (CA) signiert werden, die sich im AWS Trust Store befindet.
Anweisungen zum Generieren eines Client-Zertifikats finden Sie unter Einführung der gegenseitigen TLS Authentifizierung für Amazon MSK als Ereignisquelle
Amazon unterstützt MSK keine selbstsignierten Serverzertifikate, da alle Broker in Amazon öffentliche Zertifikate MSK verwenden, die von Amazon Trust Services
Weitere Informationen zu m TLS for Amazon MSK finden Sie unter Mutual TLS Authentication im Amazon Managed Streaming for Apache Kafka Developer Guide.
Konfiguration von m Secret TLS
Das CLIENT _ _ CERTIFICATE TLS _ AUTH Secret erfordert ein Zertifikatsfeld und ein Feld für den 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-----" }
So wählt Lambda einen Bootstrap-Broker
Lambda wählt einen Bootstrap-Broker basierend auf den auf Ihrem Cluster verfügbaren Authentifizierungsmethoden aus und ob Sie ein Geheimnis für die Authentifizierung angeben.. Wenn Sie ein Geheimnis für m TLS oderSASL/angebenSCRAM, wählt Lambda automatisch diese Authentifizierungsmethode. Wenn Sie kein Geheimnis angeben, wählt Lambda die stärkste Authentifizierungsmethode aus, die in Ihrem Cluster aktiv ist. Im Folgenden ist die Reihenfolge der Priorität aufgeführt, in der Lambda einen Broker auswählt, von der stärksten zur schwächsten Authentifizierung:
m TLS (für m bereitgestelltes Geheimnis) TLS
SASL/SCRAM(Geheimnis vorgesehen fürSASL/SCRAM)
SASLIAM(kein Geheimnis angegeben und IAM Authentifizierung aktiv)
Nicht authentifiziert TLS (kein Geheimnis angegeben und IAM Authentifizierung nicht aktiv)
Klartext (kein Geheimnis angegeben, und sowohl IAM auth als auch unauthenticated sind nicht aktiv) TLS
Anmerkung
Wenn Lambda keine Verbindung zum sichersten Brokertyp herstellen kann, versucht Lambda nicht, eine Verbindung zu einem anderen (schwächeren) Brokertyp herzustellen. Wenn Sie möchten, dass Lambda einen schwächeren Brokertyp wählt, deaktivieren Sie alle stärkeren Authentifizierungsmethoden in Ihrem Cluster.
Verwaltung des Zugriffs und der Berechtigungen API
Zusätzlich zum Zugriff auf den MSK Amazon-Cluster benötigt Ihre Funktion Berechtigungen, um verschiedene MSK API Amazon-Aktionen auszuführen. Sie fügen diese Berechtigungen zur Ausführungsrolle der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf eine der MSK API Amazon-Aktionen benötigen, fügen Sie der Identitätsrichtlinie für den Benutzer oder die Rolle die erforderlichen Berechtigungen hinzu.
Sie können Ihrer Ausführungsrolle jede der folgenden Berechtigungen manuell hinzufügen. Alternativ können Sie die AWS verwaltete Richtlinie AWSLambdaMSKExecutionRolean Ihre Ausführungsrolle anhängen. Die AWSLambdaMSKExecutionRole
Richtlinie enthält alle unten aufgeführten erforderlichen API Aktionen und VPC Berechtigungen.
Erforderliche Berechtigungen für Ausführungsrolle der Lambda-Funktion
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:
Damit Lambda in Ihrem Namen auf Ihren MSK Amazon-Cluster zugreifen kann, muss Ihre Lambda-Funktion in ihrer Ausführungsrolle über die folgenden Berechtigungen verfügen:
Sie müssen nur entweder kafka:DescribeCluster
oder kafka:DescribeClusterV2
hinzufügen. Bei bereitgestellten MSK Clustern funktioniert jede der beiden Berechtigungen. Für serverlose MSK Cluster müssen Sie verwenden. kafka:DescribeClusterV2
Anmerkung
Lambda plant, schließlich die kafka:DescribeCluster
-Genehmigung aus dieser AWSLambdaMSKExecutionRole
-Richtlinie zu entfernen. Wenn Sie diese Richtlinie verwenden, sollten Sie alle Anwendungen, die kafka:DescribeCluster
verwendet, auf kafka:DescribeClusterV2
umstellen.
VPCBerechtigungen
Wenn nur Benutzer innerhalb eines auf Ihren MSK Amazon-Cluster zugreifen VPC können, muss Ihre Lambda-Funktion über die Berechtigung verfügen, auf Ihre VPC Amazon-Ressourcen zuzugreifen. Zu diesen Ressourcen gehören IhreVPC, Subnetze, Sicherheitsgruppen und Netzwerkschnittstellen. Um auf diese Ressourcen zugreifen zu können, muss die Ausführungsrolle Ihrer Funktion über die folgenden Berechtigungen verfügen. Diese Berechtigungen sind in der AWSLambdaMSKExecutionRole AWS verwalteten Richtlinie enthalten.
Optionale Lambda-Funktionsberechtigungen
Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes:
-
Greifen Sie auf Ihr SCRAM Geheimnis zu, wenn Sie die SCRAM AuthentifizierungSASL/verwenden.
-
Beschreiben Ihres Secrets-Manager-Secrets
-
Greifen Sie auf Ihren AWS Key Management Service (AWS KMS) vom Kunden verwalteten Schlüssel zu.
-
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 MSK Amazon-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Erlaubnis, auf Ihr SCRAM Geheimnis zuzugreifen (wenn SieSASL/SCRAMauthentication verwenden) oder Secrets Manager-Geheimnis, um 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:
Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle
Gehen Sie wie folgt vor, um die AWS verwaltete Richtlinie mithilfe der Konsole AWSLambdaMSKExecutionRolezu Ihrer Ausführungsrolle hinzuzufügen. IAM
Um eine AWS verwaltete Richtlinie hinzuzufügen
-
Öffnen Sie die Seite Richtlinien
der IAM Konsole. -
Geben Sie im Suchfeld den Namen der Richtlinie ein (
AWSLambdaMSKExecutionRole
). -
Wählen Sie die Richtlinie aus der Liste aus und wählen Sie dann Richtlinienaktionen, Anhängen aus.
-
Wählen Sie auf der Seite Richtlinie anfügen Ihre Ausführungsrolle aus der Liste aus, und wählen Sie dann Richtlinie anfügen aus.
Benutzern Zugriff mit einer IAM Richtlinie gewähren
Standardmäßig sind Benutzer und Rollen nicht berechtigt, MSK API Amazon-Operationen durchzuführen. Um Benutzern in Ihrem Unternehmen oder Konto Zugriff zu gewähren, können Sie eine identitätsbasierte Richtlinie hinzufügen oder aktualisieren. Weitere Informationen finden Sie unter Amazon MSK Identity-Based Policy Examples im Amazon Managed Streaming for Apache Kafka Developer Guide.
Authentifizierungs- und Autorisierungsfehler
Wenn eine der für die Nutzung von Daten aus dem MSK Amazon-Cluster erforderlichen Berechtigungen fehlt, zeigt Lambda in der Ereignisquellenzuordnung unter LastProcessingResulteine der folgenden Fehlermeldungen an.
Fehlermeldungen
Cluster konnte Lambda nicht autorisieren
FürSASL/SCRAModer m bedeutet dieser FehlerTLS, dass der angegebene Benutzer nicht über alle der folgenden erforderlichen Berechtigungen auf der Kafka-Zugriffskontrollliste (ACL) verfügt:
DescribeConfigs Cluster
Beschreiben von Gruppe
Gruppe lesen
Thema beschreiben
Thema lesen
Für die IAM Zugriffskontrolle fehlen in der Ausführungsrolle Ihrer Funktion eine oder mehrere der Berechtigungen, die für den Zugriff auf die Gruppe oder das Thema erforderlich sind. Prüfen Sie die Liste der erforderlichen Berechtigungen in Auf IAM-Rolle basierende Authentifizierung.
Wenn Sie entweder Kafka ACLs oder eine IAM Richtlinie mit den erforderlichen Kafka-Cluster-Berechtigungen erstellen, geben Sie das Thema und die Gruppe als Ressourcen an. Der Themenname muss mit dem Thema in der Ereignisquellenzuordnung übereinstimmen. Der Gruppenname muss mit dem der Ereignisquellenzuordnung übereinstimmen. UUID
Nachdem Sie der Ausführungsrolle die erforderlichen Berechtigungen hinzugefügt haben, kann es einige Minuten dauern, bis die Änderungen wirksam werden.
SASLDie Authentifizierung ist fehlgeschlagen
FürSASL/bedeutet dieser FehlerSCRAM, dass der angegebene Benutzername und das Passwort nicht gültig sind.
Für die IAM Zugriffskontrolle fehlt der Ausführungsrolle die kafka-cluster:Connect
Berechtigung für den MSK Cluster. Fügen Sie der Rolle diese Berechtigung hinzu und geben Sie den Amazon-Ressourcennamen (ARN) des Clusters als Ressource an.
Dieser Fehler wird Ihnen möglicherweise in zeitlichen Abständen angezeigt. Der Cluster lehnt Verbindungen ab, wenn die Anzahl der TCP Verbindungen das Amazon MSK Service-Kontingent überschreitet. Lambda zieht sich zurück und versucht es erneut, bis eine Verbindung erfolgreich ist. Nachdem Lambda eine Verbindung zum Cluster hergestellt hat und nach Datensätzen abfragt, ändert sich das letzte Verarbeitungsergebnis zu OK
.
Server konnte Lambda nicht authentifizieren
Dieser Fehler weist darauf hin, dass sich die Amazon MSK Kafka-Broker nicht bei Lambda authentifizieren konnten. Dieser Fehler kann aus folgenden Gründen auftreten:
Sie haben kein Client-Zertifikat für meine Authentifizierung bereitgestellt. TLS
Sie haben ein Client-Zertifikat bereitgestellt, aber die Broker sind nicht für die Verwendung von m konfiguriertTLS.
Die Broker vertrauen einem Client-Zertifikat nicht.
Bereitgestelltes Zertifikat oder bereitgestellter privater Schlüssel ist ungültig
Dieser Fehler weist darauf hin, dass der MSK Amazon-Verbraucher das bereitgestellte Zertifikat oder den privaten Schlüssel nicht verwenden konnte. Stellen Sie sicher, dass das Zertifikat und der Schlüssel das PEM Format verwenden und dass die Verschlüsselung mit dem privaten Schlüssel einen PBES1 Algorithmus verwendet.
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 MSK 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.
Ihre VPC Amazon-Konfiguration ist über Amazon MSK API auffindbar. Sie müssen sie während der Einrichtung nicht mit dem Befehl create-event-source-mapping konfigurieren.
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 Sie den gesamten Datenverkehr auf dem MSK Amazon-Broker-Port (9092 für Klartext, 9094 für, 9096 fürTLS, 9098 fürIAM) für die Sicherheitsgruppen zuSASL, die für Ihre Ereignisquelle angegeben sind.
-
Ausgehende Regeln - Erlauben Sie allen Datenverkehr auf Port 443 für alle Ziele. Lassen Sie den gesamten Verkehr auf dem MSK Amazon-Broker-Port (9092 für Klartext, 9094 fürTLS, 9096 fürSASL, 9098 fürIAM) für die für Ihre Ereignisquelle angegebenen Sicherheitsgruppen zu.
-
Wenn Sie VPC Endpunkte anstelle eines NAT Gateways verwenden, müssen die mit den VPC Endpunkten verknüpften Sicherheitsgruppen den gesamten eingehenden Datenverkehr über Port 443 von 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 dem Lambda-Serviceprinzip den Aufruf von und ermöglichen. 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:PutObject
sns:Publish
, oder sqs:sendMessage
mithilfe des von Lambda verwalteten Systems aufzurufen. ENIs