Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Configuration de sources d'événements Apache Kafka autogérées pour Lambda
Avant de créer un mappage de source d'événements pour votre cluster Apache Kafka autogéré, vous devez vous assurer que votre cluster et celui dans lequel VPC il réside sont correctement configurés. Vous devez également vous assurer que le rôle d'exécution de votre fonction Lambda dispose des autorisations nécessairesIAM.
Suivez les instructions des sections suivantes pour configurer votre cluster Apache Kafka autogéré et votre fonction Lambda. Pour savoir comment créer le mappage des sources d'événements, consultezAjout d’un cluster Kafka en tant que source d’événement.
Rubriques
Authentification de cluster Kafka
Lambda prend en charge plusieurs méthodes d’authentification auprès de votre cluster Apache Kafka autogéré. Veillez à configurer le cluster Kafka pour utiliser l’une des méthodes d’authentification prises en charge suivantes : Pour de plus amples informations sur la sécurité, veuillez consulter la section Sécurité
VPCaccès
Si seuls les utilisateurs Kafka de votre entourage ont VPC accès à vos courtiers Kafka, vous devez configurer la source d'événements Kafka pour l'accès à Amazon Virtual Private Cloud (AmazonVPC).
SASL/SCRAMauthentification
Lambda prend en charge l'authentification simple et l'authentification par couche de sécurité/mécanisme d'authentification Salted Challenge Response (SASL/SCRAM) avec le chiffrement Transport Layer Security (TLS) (). SASL_SSL Lambda envoie les informations d’identification chiffrées pour s’authentifier auprès du cluster. Lambda ne supporte pasSASL/SCRAMavec plaintext (). SASL_PLAINTEXT Pour plus d'informations sur SCRAM l'authentificationSASL/, consultez RFC5802
Lambda prend également en charge l'authentification SASL /. PLAIN Comme ce mécanisme utilise des informations d'identification en texte clair, la connexion au serveur doit être TLS cryptée pour garantir la protection des informations d'identification.
Pour SASL l'authentification, vous stockez les informations de connexion sous forme de code secret dans AWS Secrets Manager. Pour plus d’informations sur l’utilisation de Secrets Manager, consultez Didacticiel : création et récupération d’un secret dans le Guide de l’utilisateur AWS Secrets Manager .
Important
Pour utiliser Secrets Manager pour l'authentification, les secrets doivent être stockés dans la même AWS région que votre fonction Lambda.
TLSAuthentification mutuelle
Mutual TLS (mTLS) fournit une authentification bidirectionnelle entre le client et le serveur. Le client envoie un certificat au serveur pour que le serveur vérifie le client, et le serveur envoie un certificat au client pour que le client vérifie le serveur.
Dans Apache Kafka autogéré, Lambda agit en tant que client. Vous configurez un certificat client (en tant que secret dans Secrets Manager) pour authentifier Lambda auprès des courtiers Kafka. Le certificat client doit être signé par une autorité de certification dans le magasin d’approbations du serveur.
Le cluster Kafka envoie un certificat de serveur à Lambda pour authentifier les courtiers auprès de Lambda. Le certificat de serveur peut être un certificat d’autorité de certification public ou un certificat CA/auto-signé privé. Le certificat d’autorité de certification publique doit être signé par une autorité de certification située du magasin d’approbations Lambda. Pour un certificat CA/auto-signé privé, vous configurez le certificat d’autorité de certification racine du serveur (en tant que secret dans Secrets Manager). Lambda utilise le certificat racine pour vérifier les courtiers Kafka.
Pour plus d'informations sur mTLS, consultez Présentation de TLS l'authentification mutuelle pour Amazon MSK en tant que source d'événements
Configuration du secret du certificat client
Le AUTH secret CLIENT CERTIFICATE _ TLS _ _ nécessite un champ de certificat et un champ de clé privée. Pour une clé privée chiffrée, le secret nécessite un mot de passe de clé privée. Le certificat et la clé privée doivent tous deux être au PEM format.
Note
Lambda prend en charge les algorithmes de chiffrement par clé privée PBES1
Le champ de certificat doit contenir une liste de certificats, commençant par le certificat client, suivi de tous les certificats intermédiaires et se terminant par le certificat racine. Chaque certificat doit commencer sur une nouvelle ligne avec la structure suivante :
-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----
Secrets Manager prend en charge les secrets jusqu’à 65 536 octets, ce qui offre suffisamment d’espace pour de longues chaînes de certificats.
La clé privée doit être au format PKCS#8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Pour une clé privée chiffrée, utilisez la structure suivante :
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
L'exemple suivant montre le contenu d'un secret pour mon TLS authentification à l'aide d'une clé privée cryptée. Pour une clé privée chiffrée, incluez le mot de passe de clé privée dans le secret.
{"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-----" }
Configuration du secret du certificat d’autorité de certification racine du serveur
Vous créez ce secret si vos courtiers Kafka utilisent le TLS chiffrement avec des certificats signés par une autorité de certification privée. Vous pouvez utiliser TLS le chiffrement pour l'TLSauthentification VPC SCRAMPLAIN, SASLSASL/,/ou m.
Le secret du certificat de l'autorité de certification racine du serveur nécessite un champ contenant le PEM format du certificat de l'autorité de certification racine du courtier Kafka. La structure du secret est présentée dans l’exemple suivant.
{"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" }
Configuration réseau
Pour que Lambda puisse utiliser votre cluster Kafka comme source d'événements, il doit avoir accès à l'Amazon dans lequel réside VPC votre cluster. Nous vous recommandons de déployer des AWS PrivateLink VPCpoints de terminaison pour que Lambda puisse accéder à votre. VPC Déployez des points de terminaison pour Lambda AWS Security Token Service et AWS STS(). Si le broker utilise l'authentification, déployez également un VPC point de terminaison pour Secrets Manager. Si vous avez configuré une destination en cas de défaillance, déployez également un VPC point de terminaison pour le service de destination.
Vous pouvez également vous assurer que le cluster VPC associé à votre cluster Kafka inclut une NAT passerelle par sous-réseau public. Pour de plus amples informations, veuillez consulter Activer l'accès à Internet pour les VPC fonctions Lambda connectées.
Si vous utilisez des VPC points de terminaison, vous devez également les configurer pour activer les DNS noms privés.
Lorsque vous créez un mappage de source d'événements pour un cluster Apache Kafka autogéré, Lambda vérifie si des interfaces réseau élastiques (ENIs) sont déjà présentes pour les sous-réseaux et les groupes de sécurité de votre cluster. VPC Si Lambda trouve des objets existantsENIs, il essaie de les réutiliser. Sinon, Lambda en crée un nouveau ENIs pour se connecter à la source de l'événement et appeler votre fonction.
Note
Les fonctions Lambda s'exécutent toujours au sein VPCs du service Lambda. Ils VPCs sont gérés automatiquement par le service et ne sont pas visibles pour les clients. Vous pouvez également connecter votre fonction à un AmazonVPC. Dans les deux cas, la VPC configuration de votre fonction n'affecte pas le mappage des sources d'événements. Seule la configuration des sources d'événements VPC détermine la manière dont Lambda se connecte à votre source d'événements.
Pour plus d'informations sur la configuration du réseau, voir Configuration AWS Lambda avec un cluster Apache Kafka au sein d'un
VPCrègles du groupe de sécurité
Configurez les groupes de sécurité pour l'Amazon VPC contenant votre cluster avec les règles suivantes (au minimum) :
-
Règles entrantes – Autorisent tout le trafic sur le port de l’agent Kafka pour le groupe de sécurité spécifié en tant que source d’évènement. Kafka utilise le port 9092 par défaut.
-
Règles sortantes : autorisent tout le trafic sur le port 443 pour toutes les destinations. Autorisent tout le trafic sur le port de l’agent Kafka pour le groupe de sécurité spécifié en tant que source d’évènement. Kafka utilise le port 9092 par défaut.
-
Si vous utilisez des VPC points de terminaison au lieu d'une NAT passerelle, les groupes de sécurité associés aux VPC points de terminaison doivent autoriser tout le trafic entrant sur le port 443 en provenance des groupes de sécurité de la source de l'événement.
Utilisation de points de terminaison VPC
Lorsque vous utilisez des VPC points de terminaison, API les appels pour appeler votre fonction sont acheminés via ces points de terminaison à l'aide du. ENIs Le principal du service Lambda doit appeler sts:AssumeRole et appeler tous lambda:InvokeFunction les rôles et fonctions qui les utilisent. ENIs
Par défaut, les VPC points de terminaison ont IAM des politiques ouvertes. La meilleure pratique consiste à restreindre ces politiques afin de n'autoriser que des principaux spécifiques à effectuer les actions nécessaires à l'aide de ce point de terminaison. Pour garantir que le mappage de votre source d'événements est en mesure d'appeler votre fonction Lambda, la politique du VPC point de terminaison doit autoriser le principe du service Lambda à appeler et. sts:AssumeRole lambda:InvokeFunction Le fait de restreindre les politiques de vos VPC terminaux pour autoriser uniquement les API appels provenant de votre organisation empêche le mappage des sources d'événements de fonctionner correctement.
Les exemples de politiques de point de VPC terminaison suivants montrent comment accorder l'accès requis au principal de service Lambda pour les points de terminaison Lambda et AWS STS Lambda.
Exemple VPCpolitique relative aux terminaux - AWS STS points de terminaison
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Exemple VPCpolitique de point de terminaison - point de terminaison Lambda
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Si votre courtier Kafka utilise l'authentification, vous pouvez également restreindre la politique de point de VPC terminaison pour le point de terminaison Secrets Manager. Pour appeler le Secrets ManagerAPI, Lambda utilise votre rôle fonctionnel, et non le principal du service Lambda. L'exemple suivant montre une politique de point de terminaison de Secrets Manager.
Exemple VPCpolitique relative aux points de terminaison - Point de terminaison Secrets Manager
{ "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "customer_function_execution_role_arn" ] }, "Resource": "customer_secret_arn" } ] }
Si vous avez configuré une destination en cas de défaillance, Lambda utilise également le rôle de votre fonction pour appeler s3:PutObject soitsns:Publish, sqs:sendMessage soit en utilisant le Lambda Géré. ENIs
APIautorisations d'accès et de fonction Lambda
En plus d'accéder à votre cluster Kafka autogéré, votre fonction Lambda a besoin d'autorisations pour effectuer diverses actions. API Ajoutez ces autorisations au rôle d’exécution de votre fonction. Si vos utilisateurs ont besoin d'accéder à des API actions, ajoutez les autorisations requises à la politique d'identité de l'utilisateur ou du rôle AWS Identity and Access Management (IAM).
Autorisations de fonction Lambda requises
Pour créer et stocker des journaux dans un groupe de CloudWatch journaux dans Amazon Logs, votre fonction Lambda doit disposer des autorisations suivantes dans son rôle d'exécution :
Autorisations de fonction Lambda facultatives
Votre fonction Lambda peut également nécessiter ces autorisations pour :
-
Décrivez votre secret Secrets Manager.
-
Accédez à votre AWS Key Management Service (AWS KMS) clé gérée par le client.
-
Accédez à votre AmazonVPC.
-
Envoyez les enregistrements des invocations ayant échoué vers une destination.
Secrets Manager et AWS KMS autorisations
Selon le type de contrôle d'accès que vous configurez pour vos courtiers Kafka, votre fonction Lambda peut avoir besoin d'une autorisation pour accéder à votre secret Secrets Manager ou pour déchiffrer AWS KMS votre clé gérée par le client. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes :
VPCautorisations
Si seuls les utilisateurs d'un VPC peuvent accéder à votre cluster Apache Kafka autogéré, votre fonction Lambda doit être autorisée à accéder à vos ressources Amazon. VPC Ces ressources incluent vos sous-réseauxVPC, vos groupes de sécurité et vos interfaces réseau. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes :
Ajout d’autorisations à votre rôle d’exécution
Par défaut, Lambda n’est pas autorisé à exécuter les actions obligatoires ou facultatives pour un cluster Apache Kafka autogéré. Vous devez créer et définir ces actions dans une politique de IAM confiance pour votre rôle d'exécution. Cet exemple montre comment créer une politique permettant à Lambda d'accéder à vos ressources AmazonVPC.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] }
Accorder l'accès aux utilisateurs avec une IAM politique
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à effectuer des APIopérations sur les sources d'événements. Pour accorder l’accès aux utilisateurs de votre organisation ou de votre compte, vous pouvez ajouter ou mettre à jour une stratégie basée sur l’identité. Pour plus d'informations, consultez la section Contrôle de l'accès aux AWS ressources à l'aide de politiques dans le Guide de IAM l'utilisateur.
