Konfigurieren von selbstverwalteten Apache Kafka-Ereignisquellen für Lambda

Bevor Sie eine Zuordnung von Ereignisquellen für Ihren selbstverwalteten Apache Kafka-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 selbstverwalteten Apache Kafka-Cluster und Ihre Lambda-Funktion zu konfigurieren. Wie Sie die Zuordnung von Ereignisquellen erstellen können, erfahren Sie unter Hinzufügen eines Kafka-Clusters als Ereignisquelle.

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 in der Kafka-Dokumentation.

SASL/SCRAM-Authentifizierung

Lambda unterstützt die Authentifizierung mit Transport Layer Security (TLS)-Verschlüsselung (SASL_SSL) von Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM). Lambda sendet die verschlüsselten Anmeldeinformationen zur Authentifizierung mit dem Cluster. Lambda unterstützt SASL/SCRAM mit Klartext (SASL_PLAINTEXT) nicht. Weitere Informationen zur IAM-Authentifizierung finden Sie unter RFC 5802.

Lambda unterstützt auch die 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 im Tutorial: Erstellen und Abrufen eines Secrets im Benutzerhandbuch für AWS Secrets Manager.

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 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 über mTLS finden Sie unter Vorstellung von gegenseitiger TLS-Authentifizierung für Amazon MSK als Ereignisquelle.

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.

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

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 zur VPC-, SASL/SCRAM-, SASL/PLAIN- oder mTLS-Authentifizierung verwenden.

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

API-Zugriff und Lambda-Funktionsberechtigungen

Neben dem Zugriff auf Ihren selbstverwalteten Kafka-Cluster benötigt Ihre Lambda-Funktion auch Berechtigungen, um verschiedene API-Aktionen auszuführen. Sie fügen diese Berechtigungen zur Ausführungsrolle der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf API-Aktionen benötigen, fügen Sie die erforderlichen Berechtigungen zur Identitätsrichtlinie für den AWS Identity and Access Management(IAM)-Benutzer oder die IAM-Rolle hinzu.

Benötigte Lambda-Funktionsberechtigungen

Um Protokolle in einer Protokollgruppe in Amazon CloudWatch Logs zu erstellen und zu speichern, muss Ihre Lambda-Funktion die folgenden Berechtigungen in ihrer Ausführungsrolle haben:

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 Zugriffssteuerung, die Sie für Ihre Kafka-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Berechtigung, auf Ihr Secrets-Manager-Secret zuzugreifen oder Ihren vom Kunden verwalteten AWS KMS-Schlüssel zu entschlüsseln. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen:

VPC-Berechtigungen

Wenn nur Benutzer innerhalb einer VPC auf Ihren selbstverwalteten Apache-Kafka-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:

Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle

Um auf andere AWS-Services zuzugreifen, die Ihr selbstverwaltetes Apache-Kafka-Cluster verwendet, verwendet Lambda die Berechtigungsrichtlinien, die Sie in der Ausführungsrolle Ihrer Lambda-Funktion definieren.

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 IAM-Vertrauensrichtlinie für Ihre Ausführungsrolle erstellen und definieren. In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen können, die Lambda den Zugriff auf Ihre Amazon-VPC-Ressourcen erlaubt.

{
        "Version":"2012-10-17",
        "Statement":[
           {
              "Effect":"Allow",
              "Action":[
                 "ec2:CreateNetworkInterface",
                 "ec2:DescribeNetworkInterfaces",
                 "ec2:DescribeVpcs",
                 "ec2:DeleteNetworkInterface",
                 "ec2:DescribeSubnets",
                 "ec2:DescribeSecurityGroups"
              ],
              "Resource":"*"
           }
        ]
     }

Gewähren von Benutzerzugriff mit einer IAM-Richtlinie

Standardmäßig haben Benutzer und Rollen keine Berechtigung zum Ausführen von Ereignisquellen-API-Vorgängen. Um Benutzern in Ihrem Unternehmen oder Ihrem Konto Zugriff zu gewähren, erstellen oder aktualisieren Sie eine identitätsbasierte Richtlinie. Weitere Informationen finden Sie unter Steuern des Zugriffs auf AWS-Ressourcen mithilfe von Richtlinien im IAM-Benutzerhandbuch.

Konfigurieren Sie die Netzwerksicherheit

Um Lambda vollen Zugriff auf selbstverwaltetes Apache Kafka ü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 selbstverwaltetes Apache Kafka 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 Zuordnung von Ereignisquellen für selbstverwaltetes Apache Kafka erstellen, prüft Lambda, ob Elastic-Network-Schnittstelle (ENI) für die für Ihre Amazon VPC konfigurierten Subnetze und Sicherheitsgruppen bereits vorhanden sind. Findet Lambda vorhandene ENIs, versucht es, diese wiederzuverwenden. Andernfalls erstellt Lambda neue ENIs, um eine Verbindung mit der Ereignisquelle herzustellen und Ihre Funktion aufzurufen.

Konfigurieren Sie die Sicherheitsgruppen für die Amazon VPC, die Ihren Cluster enthält. Standardmäßig verwendet der selbstverwaltete Apache Kafka die folgenden Ports: 9092.

Wenn Ihr Cluster 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-Dienstprinzipal.

{
      "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, leitet AWS Ihre API-Aufrufe weiter, um Ihre Funktion über die Elastic-Network-Schnittstelle (ENI) des Endpunkts aufzurufen. Der Prinzipal des Lambda-Dienstes muss lambda:InvokeFunction für alle Rollen und Funktionen aufrufen, die diese ENI 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-Dienstprinzipal 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-Dienstprinzipal 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": "*"
          }
      ]
  }