Konfigurieren von Amazon MSK-Ereignisquellen für Lambda

Bevor Sie eine Zuordnung von Ereignisquellen für Ihren Amazon MSK-Cluster erstellen, müssen Sie sicherstellen, dass Ihr Cluster und die VPC, in der 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 Amazon MSK-Cluster, Ihre VPC und Ihre Lambda-Funktion zu konfigurieren. Wie Sie die Zuordnung von Ereignisquellen erstellen können, erfahren Sie unter Hinzufügen von Amazon MSK als Ereignisquelle.

MSK-Cluster-Authentifizierung

Lambda benötigt eine Berechtigung, um auf den Amazon-MSK-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.

Nicht authentifizierter Zugriff

Wenn keine Clients über das Internet auf den Cluster zugreifen, können Sie einen nicht authentifizierten Zugriff verwenden.

SASL/SCRAM-Authentifizierung

Amazon MSK unterstützt die Authentifizierung (Simple Authentication and SecurityLayer/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 MSK unterstützt die SASL/PLAIN-Authentifizierung nicht.

Auf IAM-Rolle basierende Authentifizierung

Sie können IAM verwenden, um die Identität von Clients zu authentifizieren, die sich mit dem MSK-Cluster verbinden. Wenn die IAM-Authentifizierung auf Ihrem MSK-Cluster aktiv ist und Sie kein Geheimnis für die Authentifizierung angeben, verwendet Lambda automatisch standardmäßig die IAM-Authentifizierung. Verwenden Sie die IAM-Konsole oder API, um Richtlinien zu erstellen und zu implementieren, die auf Benutzern oder Rollen basieren. Weitere Informationen finden Sie unter IAM-Zugriffskontrolle im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

Fügen Sie die folgenden Berechtigungen zur Ausführungsrolle Ihrer Funktion hinzu, um Lambda zu erlauben, sich mit dem MSK-Cluster zu verbinden, Datensätze zu lesen und andere erforderliche Aktionen auszuführen.

{
    "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 unter Amazon-MSK-Kafka-Aktionen im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

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.

Für Amazon MSK fungiert Lambda als der Client. Sie konfigurieren ein Client-Zertifikat (als Secret in Secrets Manager), um Lambda für die Broker 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 für Lambda zu authentifizieren. Das Serverzertifikat muss von einer Zertifizierungsstelle (CA) signiert sein, die sich im AWS Trust Store befindet.

Informationen dazu, wie Sie ein Client-Zertifikat generieren, finden Sie unter Vorstellung von gegenseitiger TLS-Authentifizierung für Amazon MSK als Ereignisquelle.

Amazon MSK unterstützt keine selbstsignierten Serverzertifikate, da alle Broker in Amazon MSK öffentliche Zertifikate verwenden, die von Amazon Trust Services signiert wurden CAs, denen Lambda standardmäßig vertraut.

Weitere Informationen über mTLS für Amazon MSK finden Sie unter Gegenseitige TLS-Authentifizierung im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

Konfigurieren des mTLS-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.

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 mit folgender Struktur vorliegen:

-----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-----"
} 

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 MTLs oder SASL/SCRAM angeben, 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:

Verwalten von API-Zugriff und -Berechtigungen

Neben dem Zugriff auf den Amazon-MSK-Cluster benötigt Ihre Funktion auch Berechtigungen, um verschiedene Amazon-MSK-API-Aktionen auszuführen. Sie fügen diese Berechtigungen zur Ausführungsrolle der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf Amazon-MSK-API-Aktionen benötigen, fügen Sie die erforderlichen Berechtigungen zur Identitätsrichtlinie für den Benutzer oder die Rolle hinzu.

Sie können Ihrer Ausführungsrolle jede der folgenden Berechtigungen manuell hinzufügen. Alternativ können Sie die AWSLambdaMSKExecutionRolle für AWS verwaltete Richtlinien an 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 Amazon-MSK-Cluster zugreifen kann, muss Ihre Lambda-Funktion über die folgenden Berechtigungen in ihrer Ausführungsrolle verfügen:

Sie müssen nur entweder kafka:DescribeCluster oder kafka:DescribeClusterV2 hinzufügen. Für bereitgestellte MSK-Cluster funktioniert jede der beiden Berechtigungen. Für Serverless-MSK-Cluster müssen Sie kafka:DescribeClusterV2 verwenden.

VPC-Berechtigungen

Wenn nur Benutzer innerhalb einer VPC auf Ihren Amazon-MSK-Cluster zugreifen können, muss Ihre Lambda-Funktion die Berechtigung zum Zugriff auf Ihre Amazon-VPC-Ressourcen haben. Zu diesen Ressourcen gehören Ihre VPC, Subnetze, Sicherheitsgruppen und Netzwerkschnittstellen. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen. Diese Berechtigungen sind in der Richtlinie „AWSLambdaMSKExecution AWS Rollenverwaltung“ enthalten.

Optionale Lambda-Funktionsberechtigungen

Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes:

Secrets Manager und AWS KMS Berechtigungen

Abhängig von der Art der Zugriffskontrolle, die Sie für Ihre Amazon MSK-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Erlaubnis, auf Ihr SCRAM-Secret (wenn Sie SASL/SCRAM-Authentifizierung verwenden) oder auf Secrets Manager-Geheimnis zuzugreifen, um Ihren vom Kunden verwalteten Schlüssel zu entschlüsseln. AWS KMS 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 AWSLambdaMSKExecutionPolicy-Rolle mithilfe der IAM-Konsole zu Ihrer Ausführungsrolle hinzuzufügen.

Gewähren von Benutzerzugriff mit einer IAM-Richtlinie

Standardmäßig haben Benutzer und Rollen keine Berechtigung zum Ausführen von Amazon-MSK-API-Operationen. 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 Beispiele für identitätsbasierte Amazon-MSK-Richtlinien im Entwicklerhanbuch für Amazon Managed Streaming for Apache Kafka.

Authentifizierungs- und Autorisierungsfehler

Wenn eine der für die Nutzung von Daten aus dem Amazon MSK-Cluster erforderlichen Berechtigungen fehlt, zeigt Lambda in der Ereignisquellenzuordnung unter eine der folgenden Fehlermeldungen an. LastProcessingResult

Cluster konnte Lambda nicht autorisieren

Bei SASL/SCRAM oder mTLS weist dieser Fehler darauf hin, dass der angegebene Benutzer nicht über alle nachfolgenden erforderlichen Berechtigungen für die Kafka-Zugriffskontrollliste (ACL) verfügt:

Zur IAM-Zugriffskontrolle fehlen 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 eine 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 der UUID der Ereignisquellenzuordnung übereinstimmen.

Nachdem Sie der Ausführungsrolle die erforderlichen Berechtigungen hinzugefügt haben, kann es einige Minuten dauern, bis die Änderungen wirksam werden.

SASL-Authentifizierung fehlgeschlagen

Bei SASL/SCRAM weist dieser Fehler darauf hin, dass der angegebene Benutzername und das Passwort ungültig sind.

Zur IAM-Zugriffskontrolle fehlt der Ausführungsrolle die Berechtigung kafka-cluster:Connect für den MSK-Cluster. Fügen Sie der Rolle diese Berechtigung hinzu und geben Sie den Amazon-Ressourcenname (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-Servicekontingent ü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 die Amazon-MSK-Kafka-Broker sich bei Lambda nicht authentifizieren konnten. Dieser Fehler kann aus folgenden Gründen auftreten:

Bereitgestelltes Zertifikat oder bereitgestellter privater Schlüssel ist ungültig

Dieser Fehler weist darauf hin, dass der Amazon-MSK-Konsument das bereitgestellte Zertifikat oder den bereitgestellten privaten Schlüssel nicht verwenden konnte. Stellen Sie sicher, dass das Zertifikat und der Schlüssel das PEM-Format verwenden und dass für die Verschlüsselung mit dem privaten Schlüssel ein Algorithmus verwendet wird. PBES1

Konfigurieren der Netzwerksicherheit

Um Lambda vollen Zugriff auf Amazon MSK über Ihre Zuordnung von Ereignisquellen zu ermöglichen, muss Ihr Cluster entweder einen öffentlichen Endpunkt (öffentliche IP-Adresse) verwenden oder Sie müssen Zugriff auf die Amazon VPC gewähren, in der Sie den Cluster erstellt haben.

Wenn Sie Amazon MSK mit Lambda verwenden, erstellen Sie AWS PrivateLink VPC-Endpunkte, die Ihrer Funktion Zugriff auf die Ressourcen in Ihrer Amazon VPC bieten.

Erstellen Sie einen Endpunkt, der den Zugriff auf die folgenden Ressourcen ermöglicht:

Alternativ konfigurieren Sie ein NAT-Gateway auf jedem öffentlichen Subnetz in der Amazon-VPC. Weitere Informationen finden Sie unter Aktivieren Sie den Internetzugang für VPC-verbundene Lambda-Funktionen.

Wenn Sie eine Ereignisquellenzuordnung für Amazon MSK erstellen, prüft Lambda, ob Elastic Network Interfaces (ENIs) bereits für die für Ihre Amazon VPC konfigurierten Subnetze und Sicherheitsgruppen vorhanden sind. 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.

Konfigurieren Sie die Sicherheitsgruppen für die Amazon-VPC, die Ihren Cluster enthält. Amazon MSK verwendet standardmäßig die folgenden Ports: 9092 für Klartext, 9094 für TLS, 9096 für SASL, 9098 für IAM.

Wenn Ihr Cluster eine Authentifizierung verwendet, können Sie auch die Endpunktrichtlinie für den Secrets-Manager-Endpunkt einschränken. Für den Aufruf der Secrets-Manager-API verwendet Lambda Ihre Funktionsrolle und nicht den Lambda-Serviceprinzipal.

{
      "Statement": [
          {
              "Action": "secretsmanager:GetSecretValue",
              "Effect": "Allow",
              "Principal": {
                  "AWS": [
                      "arn:aws::iam::123456789012:role/my-role"
                  ]
              },
              "Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
          }
      ]
  }

Wenn Sie Amazon VPC-Endpunkte verwenden, AWS leitet Ihre API-Aufrufe zum Aufrufen Ihrer Funktion über das Elastic Network Interface (ENI) des Endpunkts weiter. Der Lambda-Serviceprinzipal muss alle Rollen und Funktionen aufrufenlambda:InvokeFunction, die diese ENIs verwenden.

Standardmäßig verfügen Amazon VPC-Endpunkte über offene IAM-Richtlinien, die einen umfassenden Zugriff auf Ressourcen ermöglichen. Es empfiehlt sich, diese Richtlinien auf die Durchführung der erforderlichen Aktionen über diesen Endpunkt zu beschränken. Um sicherzustellen, dass Ihre Zuordnung von Ereignisquellen Ihre Lambda-Funktion aufrufen kann, muss die VPC-Endpunktrichtlinie dem Lambda-Serviceprinzipal erlauben, sts:AssumeRole und lambda:InvokeFunction aufzurufen. Wenn Sie Ihre VPC-Endpunktrichtlinien so einschränken, dass nur API-Aufrufe zugelassen werden, die aus Ihrem Unternehmen stammen, kann die Zuordnung von Ereignisquellen nicht richtig funktionieren, weshalb in diesen Richtlinien "Resource": "*" erforderlich ist.

Die folgenden Beispiel-VPC-Endpunktrichtlinien zeigen, wie der erforderliche Zugriff auf den Lambda-Serviceprinzipal für die AWS STS - und Lambda-Endpunkte gewährt wird.

{
      "Statement": [
          {
              "Action": "sts:AssumeRole",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
    }

{
      "Statement": [
          {
              "Action": "lambda:InvokeFunction",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
  }