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. # Utilisation de Lambda avec Apache Kafka autogéré Cette rubrique décrit comment utiliser Lambda avec un cluster Kafka autogéré. En AWS termes terminologiques, un cluster autogéré inclut les clusters Kafka non AWS hébergés. Par exemple, vous pouvez héberger votre cluster Kafka avec un fournisseur de cloud tel que [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/). Ce chapitre explique comment utiliser un cluster Apache Kafka autogéré en tant que source d’événement pour votre fonction Lambda. Le processus général d’intégration d’Apache Kafka autogéré à Lambda comprend les étapes suivantes : 1. **[Configuration du cluster et du réseau](with-kafka-cluster-network.md)** : configurez d’abord votre cluster Apache Kafka autogéré avec la configuration réseau appropriée pour permettre à Lambda d’accéder à votre cluster. 1. **[Configuration du mappage des sources d’événements](with-kafka-configure.md)** : créez ensuite la ressource de [mappage des sources d’événements](invocation-eventsourcemapping.md) dont Lambda a besoin pour connecter de façon sécurisée votre cluster Apache Kafka à votre fonction. 1. **[Configuration de la fonction et des autorisations](with-kafka-permissions.md)** : enfin, assurez-vous que votre fonction est correctement configurée et qu’elle dispose des autorisations nécessaires dans son [rôle d’exécution](lambda-intro-execution-role.md). Apache Kafka en tant que source d’événement fonctionne de la même manière qu’Amazon Simple Queue Service (Amazon SQS) ou Amazon Kinesis. Lambda interroge en interne les nouveaux messages de la source d’événement, puis invoque de manière synchrone la fonction Lambda cible. Lambda lit les messages par lot et les fournit à votre fonction en tant que charge utile d’événement. La taille maximale du lot est configurable (la valeur par défaut est de 100 messages). Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Pour optimiser le débit de votre mappage des sources d’événements Apache Kafka autogéré, configurez le mode alloué. En mode alloué, vous pouvez définir le nombre minimal et maximal de sondeurs d’événements alloués à votre mappage des sources d’événements. Cela peut améliorer la capacité de votre mappage des sources d’événements à gérer les pics de messages inattendus. Pour de plus amples informations, veuillez consulter [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode). **Avertissement** Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS Pour les sources d’événements basées sur Kafka, Lambda prend en charge les paramètres de contrôle du traitement par lots, tels que les fenêtres de traitement par lots et la taille des lots. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Pour un exemple d'utilisation de Kafka autogéré comme source d'événements, consultez la section [Utilisation d'Apache Kafka auto-hébergée comme source d'événements AWS Lambda sur le blog Compute](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/). AWS **Topics** + [Exemple d’évènement](#smaa-sample-event) + [Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda](with-kafka-cluster-network.md) + [Configuration des autorisations de rôle d’exécution Lambda](with-kafka-permissions.md) + [Configuration de sources d’événements Apache Kafka autogérées pour Lambda](with-kafka-configure.md) ## Exemple d’évènement Lambda envoie le lot de messages dans le paramètre d’événement quand il invoque votre fonction Lambda. La charge utile d’un événement contient un tableau de messages. Chaque élément de tableau contient des détails de la rubrique Kafka et l’identifiant de partition Kafka, ainsi qu’un horodatage et un message codé en base 64. ``` { "eventSource": "SelfManagedKafka", "bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092", "records":{ "mytopic-0":[ { "topic":"mytopic", "partition":0, "offset":15, "timestamp":1545084650987, "timestampType":"CREATE_TIME", "key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", "value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==", "headers":[ { "headerKey":[ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ] } } ``` # Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda Pour connecter votre fonction Lambda à votre cluster Apache Kafka autogéré, vous devez configurer correctement votre cluster et le réseau dans lequel il réside. Cette page décrit comment configurer votre cluster et votre réseau. Si votre cluster et votre réseau sont déjà correctement configurés, consultez [Configuration de sources d’événements Apache Kafka autogérées pour Lambda](with-kafka-configure.md) pour configurer le mappage des sources d’événements. **Topics** + [Configuration de cluster Apache Kafka autogéré](#kafka-cluster-setup) + [Configurer la sécurité réseau](#services-kafka-vpc-config) ## Configuration de cluster Apache Kafka autogéré Vous pouvez héberger votre cluster Apache Kafka autogéré auprès de fournisseurs de cloud comme [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/), ou l’exécuter sur votre propre infrastructure. Assurez-vous que votre cluster est correctement configuré et accessible depuis le réseau auquel votre mappage des sources d’événements Lambda sera connecté. ## Configurer la sécurité réseau Pour donner à Lambda un accès complet à Apache Kafka autogéré via votre mappage des sources d’événements, soit votre cluster doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé le cluster. Lorsque vous utilisez Apache Kafka autogéré avec Lambda, créez des [points de terminaison de VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC. **Note** Les points de terminaison de VPC AWS PrivateLink sont requis pour les fonctions avec des mappages de sources d’événements qui utilisent le mode par défaut (à la demande) pour les interrogateurs d’événements. Si le mappage de votre source d’événements utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), vous n’avez pas besoin de configurer les points de terminaison de VPC AWS PrivateLink. Créez un point de terminaison pour accéder aux ressources suivantes : + Lambda — Créez un point de terminaison pour le principal de service Lambda. + AWS STS — Créez un point de terminaison pour l’AWS STS afin qu’un principal de service assume un rôle en votre nom. + Secrets Manager : si votre cluster utilise Secrets Manager pour stocker les informations d’identification, créez un point de terminaison pour Secrets Manager. Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, consultez [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md). Lorsque vous créez un mappage des sources d’événements pour Apache Kafka autogéré, Lambda vérifie si des interfaces réseau Elastic (ENI) sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre VPC Amazon. Si Lambda trouve des ENI existantes, il tente de les réutiliser. Sinon, Lambda crée de nouvelles ENI pour se connecter à la source d’événement et invoquer votre fonction. **Note** Les fonctions Lambda sont toujours exécutées dans des VPC appartenant au service Lambda. La configuration VPC de votre fonction n’affecte pas le mappage des sources d’événements. Seule la configuration réseau des sources d’événements détermine la manière dont Lambda se connecte à votre source d’événements. Configurez les groupes de sécurité pour le VPC Amazon contenant votre cluster. Par défaut, Apache Kafka autogéré utilise les ports suivants : `9092`. + Règles entrantes – Autorisent tout le trafic sur le port de l’agent par défaut pour le groupe de sécurité associé à votre source d’événement. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité. + Règles sortantes : autorisent tout le trafic sur le port `443` pour des destinations externes si votre fonction doit communiquer avec des services AWS. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour limiter l’accès à l’agent si vous n’avez pas besoin de communiquer avec d’autres services AWS. + Règles entrantes relatives au point de terminaison Amazon VPC – Si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison Amazon VPC doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité du cluster. Si votre cluster utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda. **Example Politique de point de terminaison de VPC — Point de terminaison Secrets Manager** ``` { "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" } ] } ``` Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d’API pour invoquer votre fonction à l’aide de l’interface réseau Elastic (ENI) du point de terminaison. Le principal de service Lambda doit appeler `lambda:InvokeFunction` pour tous les rôles et fonctions utilisant ces ENI. Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler `sts:AssumeRole` et `lambda:InvokeFunction`. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi `"Resource": "*"` est requis dans ces politiques. Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda. **Example Politique de point de terminaison de VPC — Point de terminaison AWS STS** ``` { "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` **Example Politique de point de terminaison de VPC — Point de terminaison Lambda** ``` { "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` # Configuration des autorisations de rôle d’exécution Lambda En plus d’[accéder au cluster Amazon Kafka autogéré](kafka-cluster-auth.md), votre fonction Lambda a besoin d’autorisations pour effectuer diverses actions d’API. Ajoutez ces autorisations au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Si vos utilisateurs ont besoin d'accéder à des actions d'API, ajoutez les autorisations requises à la politique d'identité de l'utilisateur ou du rôle Gestion des identités et des accès AWS (IAM). **Topics** + [Autorisations de fonction Lambda requises](#smaa-api-actions-required) + [Autorisations de fonction Lambda facultatives](#smaa-api-actions-optional) + [Ajout d’autorisations à votre rôle d’exécution](#smaa-permissions-add-policy) + [Octroi d’accès à des utilisateurs avec une politique IAM](#smaa-permissions-add-users) ## 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 : + [journaux : CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) + [journaux : CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html) + [journaux : PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) ## 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 Amazon VPC. + 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 : + [responsable des secrets : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) + [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) ### Autorisations VPC Si seuls des utilisateurs au sein 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 les sous-réseaux, groupes de sécurité et interfaces réseau de votre VPC. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes : + [EC2 : CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html) + [EC2 : DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html) + [EC2 : DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html) + [EC2 : DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html) + [EC2 : DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) + [EC2 : DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) ## Ajout d’autorisations à votre rôle d’exécution [Pour accéder aux autres AWS services utilisés par votre cluster Apache Kafka autogéré, Lambda utilise les politiques d'autorisation que vous définissez dans le rôle d'exécution de votre fonction Lambda.](lambda-intro-execution-role.md) 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 [stratégie d’approbation IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) pour votre rôle d’exécution. Cet exemple montre comment créer une stratégie autorisant Lambda à accéder à vos ressources Amazon VPC. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] } ``` ------ ## Octroi d’accès à des utilisateurs avec une politique IAM Par défaut, les utilisateurs et les rôles n’ont pas l’autorisation d’effectuer des [opérations d’API de source d’événement](invocation-eventsourcemapping.md#event-source-mapping-api). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) dans le *Guide de l'utilisateur IAM*. Pour résoudre les erreurs d’authentification et d’autorisation, consultez [Résolution des erreurs de mappage des sources d’événements Kafka](with-kafka-troubleshoot.md). # Configuration de sources d’événements Apache Kafka autogérées pour Lambda Pour utiliser un cluster Apache Kafka autogéré en tant que source d’événements pour votre fonction Lambda, vous devez créer un [mappage des sources d’événements](invocation-eventsourcemapping.md) qui connecte les deux ressources. Cette page explique comment créer un mappage des sources d’événements pour Apache Kafka autogéré. Cette page suppose que vous avez déjà correctement configuré votre cluster Kafka et le réseau dans lequel il réside. Si vous devez configurer votre cluster ou votre réseau, consultez [Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda](with-kafka-cluster-network.md). **Topics** + [Utilisation d’un cluster Apache Kafka autogéré comme source d’événement](#kafka-esm-overview) + [Configuration des méthodes d’authentification de cluster dans Lambda](kafka-cluster-auth.md) + [Création d’un mappage des sources d’événements Lambda pour une source d’événements Apache Kafka autogéré](kafka-esm-create.md) + [Tous les paramètres de configuration des sources d’événements Apache Kafka autogéré dans Lambda](kafka-esm-parameters.md) ## Utilisation d’un cluster Apache Kafka autogéré comme source d’événement Lorsque vous ajoutez votre cluster Apache Kafka ou Amazon MSK comme déclencheur pour votre fonction Lambda, le cluster est utilisé comme [source d’événement](invocation-eventsourcemapping.md). Lambda lit les données d'événements des rubriques Kafka que vous spécifiez `Topics` dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, en fonction de la [position de départ](kafka-starting-positions.md) que vous spécifiez. Lorsque le traitement a réussi, votre rubrique Kafka est validée dans votre cluster Kafka. Lambda lit les messages séquentiellement pour chaque partition de rubrique Kafka. Une seule charge utile Lambda peut contenir des messages provenant de plusieurs partitions. Lorsque d'autres enregistrements sont disponibles, Lambda continue de traiter les enregistrements par lots, en fonction de la BatchSize valeur que vous spécifiez dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, jusqu'à ce que votre fonction aborde le sujet. Après avoir traité chaque lot, Lambda valide les décalages des messages dans celui-ci. Si votre fonction renvoie une erreur pour l’un des messages d’un lot, Lambda réessaie le lot de messages complet jusqu’à ce que le traitement réussisse ou que les messages expirent. Vous pouvez envoyer les enregistrements qui échouent à toutes les tentatives vers une destination en cas de panne pour un traitement ultérieur. **Note** Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes. # Configuration des méthodes d’authentification de cluster dans Lambda 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é](http://kafka.apache.org/documentation.html#security) de la documentation Kafka. ## Authentification SASL/SCRAM Lambda prend en charge l'authentification simple et le mécanisme d'authentification par réponse aux Layer/Salted défis de sécurité (SASL/SCRAM) avec le chiffrement TLS (Transport Layer Security) (). `SASL_SSL` Lambda envoie les informations d’identification chiffrées pour s’authentifier auprès du cluster. Lambda n'est pas compatible SASL/SCRAM avec plaintext (). `SASL_PLAINTEXT` Pour plus d'informations sur SASL/SCRAM l'authentification, consultez la [RFC 5802](https://tools.ietf.org/html/rfc5802). Lambda prend également en charge SASL/PLAIN l'authentification. Comme ce mécanisme utilise des informations d’identification en texte clair, la connexion au serveur doit utiliser le chiffrement TLS pour garantir la protection des informations d’identification. Pour l’authentification SASL, vous devez stocker les informations d’identification en tant que secret dans AWS Secrets Manager. Pour plus d'informations sur l'utilisation de Secrets Manager, consultez la section [Créer un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de AWS Secrets Manager l'utilisateur*. **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. ## Authentification TLS 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 privéCA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self, 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 de plus amples informations sur mTLS, veuillez consulter [Introduction d’une authentification TLS mutuelle pour Amazon MSK en tant que source d’événement](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source). ## Configuration du secret du certificat client Le secret CLIENT\$1CERTIFICATE\$1TLS\$1AUTH 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 être au format PEM. **Note** Lambda prend en charge les algorithmes de chiffrement par clé privée [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(mais pas PBES2). 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----- -----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 \$18](https://datatracker.ietf.org/doc/html/rfc5208), avec la structure suivante : ``` -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ``` Pour une clé privée chiffrée, utilisez la structure suivante : ``` -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- ``` L’exemple suivant affiche le contenu d’un secret pour l’authentification mTLS à l’aide d’une clé privée chiffré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 chiffrement TLS avec des certificats signés par une autorité de certification privée. Vous pouvez utiliser le chiffrement TLS pour l'authentification VPC ou SASL/SCRAM, SASL/PLAIN mTLS. Le secret du certificat d’autorité de certification racine du serveur nécessite un champ contenant le certificat d’autorité de certification racine du courtier Kafka au format PEM. La structure du secret est présentée dans l’exemple suivant. ``` {"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" } ``` # Création d’un mappage des sources d’événements Lambda pour une source d’événements Apache Kafka autogéré Pour créer un mappage des sources d’événements, vous pouvez utiliser la console Lambda, [AWS Command Line Interface (CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou un [SDK AWS](https://aws.amazon.com/getting-started/tools-sdks/). Les étapes de console suivantes ajoutent un cluster Apache Kafka autogéré en tant que déclencheur pour votre fonction Lambda. En arrière-plan, cela crée une ressource de mappage des sources d’événements. ## Conditions préalables + Cluster Apache Kafka autogéré. Lambda prend en charge Apache Kafka versions 0.10.1.0 et ultérieures. + [Rôle d'exécution](lambda-intro-execution-role.md) autorisé à accéder aux AWS ressources utilisées par votre cluster Kafka autogéré. ## Ajout d’un cluster Kafka autogéré (console) Pour ajouter votre cluster Apache Kafka autogéré et une rubrique Kafka en tant que déclencheur pour votre fonction Lambda, procédez comme suit. **Pour ajouter un déclencheur Apache Kafka à votre fonction Lambda (console)** 1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda. 1. Choisissez le nom de votre fonction Lambda. 1. Sous **Function overview** (Vue d’ensemble de la fonction), choisissez **Add trigger** (Ajouter un déclencheur). 1. Sous **Trigger configuration (Configuration du déclencheur)**, procédez comme suit : 1. Choisissez le type de déclencheur **Apache Kafka**. 1. Pour **Bootstrap servers (Serveurs d’amorçage)**, entrez l’adresse de paire hôte et port d’un agent Kafka dans votre cluster, puis choisissez **Add (Ajouter)**. Répétez l’opération pour chaque agent Kafka dans le cluster. 1. Pour **Topic name (Nom de rubrique)**, entrez le nom de la rubrique Kafka utilisée pour stocker les registres dans le cluster. 1. Si vous configurez le mode provisionné, entrez une valeur pour **Minimum Event Sollers**, une valeur pour **Maximum Event Sollers** et une valeur facultative pour PollerGroupName spécifier le regroupement de plusieurs ESMs au sein d'un même VPC source d'événements. 1. (Facultatif) Pour **Batch size (Taille de lot)**, entrez le nombre maximal de registres à recevoir dans un même lot. 1. Pour **Batch window**, veuillez saisir l’intervalle de temps maximal en secondes nécessaire à Lambda pour collecter des enregistrements avant d’invoquer la fonction. 1. (Facultatif) Pour **l’identifiant de groupe de consommateurs**, entrez l’identifiant d’un groupe de consommateurs Kafka à rejoindre. 1. (Facultatif) Pour **Position de départ**, choisissez **Dernier** pour commencer à lire le flux à partir du dernier enregistrement, **Supprimer l’horizon** pour commencer au premier enregistrement disponible ou **À l’horodatage** pour spécifier un horodatage à partir duquel commencer la lecture. 1. (Facultatif) Pour **VPC**, choisissez l’Amazon VPC pour votre cluster Kafka. Ensuite, choisissez le **VPC subnets (Sous-réseaux VPC)** et les **VPC security groups (Groupes de sécurité VPC)**. Ce paramètre est requis si seuls des utilisateurs au sein de votre VPC accèdent à vos courtiers. 1. (Facultatif) Pour **Authentication (Authentification)**, choisissez **Add (Ajouter)**, puis procédez comme suit : 1. Choisissez le protocole d’accès ou d’authentification des courtiers Kafka dans votre cluster. + Si votre broker Kafka utilise l' SASL/PLAIN authentification, choisissez **BASIC\$1AUTH**. + Si votre courtier utilise SASL/SCRAM l'authentification, choisissez l'un des **SASL\$1SCRAM**protocoles. + Si vous configurez l’authentification mTLS, choisissez le protocole **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH**. 1. Pour l' SASL/SCRAM authentification mTLS, choisissez la clé secrète de Secrets Manager qui contient les informations d'identification de votre cluster Kafka. 1. (Facultatif) Pour **Encryption (Chiffrement)**, choisissez le secret Secrets Manager contenant le certificat d’autorité de certification racine que vos courtiers Kafka utilisent pour le chiffrement TLS, si vos courtiers Kafka utilisent des certificats signés par une autorité de certification privée. Ce paramètre s'applique au chiffrement TLS pour SASL/SCRAM ou SASL/PLAIN, ainsi qu'à l'authentification MTLS. 1. Pour créer le déclencheur dans un état désactivé pour le test (recommandé), désactivez **Enable trigger** (Activer le déclencheur). Ou, pour activer le déclencheur immédiatement, sélectionnez**Activer un déclencheur**. 1. Pour créer le déclencheur, choisissez **Add** (Ajouter). ## Ajout d’un cluster Kafka autogéré (AWS CLI) Utilisez les exemples de AWS CLI commandes suivants pour créer et afficher un déclencheur Apache Kafka autogéré pour votre fonction Lambda. ### Utilisation de SASL/SCRAM Si les utilisateurs de Kafka accèdent à vos courtiers Kafka via Internet, spécifiez le secret du Gestionnaire de Secrets que vous avez créé pour SASL/SCRAM l'authentification. L'exemple suivant utilise la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI commande pour mapper une fonction Lambda nommée `my-kafka-function` à une rubrique Kafka nommée. `AWSKafkaTopic` ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Utilisation d’un VPC Si seuls des utilisateurs de Kafka au sein de votre VPC accèdent à vos agents Kafka, vous devez spécifier votre VPC, vos sous-réseaux et votre groupe de sécurité de VPC. L'exemple suivant utilise la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI commande pour mapper une fonction Lambda nommée `my-kafka-function` à une rubrique Kafka nommée. `AWSKafkaTopic` ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Affichage de l'état à l'aide du AWS CLI L'exemple suivant utilise la [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) AWS CLI commande pour décrire l'état du mappage des sources d'événements que vous avez créé. ``` aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7 ``` # Tous les paramètres de configuration des sources d’événements Apache Kafka autogéré dans Lambda Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à Apache Kafka autogéré, comme indiqué dans le tableau suivant. | Paramètre | Obligatoire | Par défaut | Remarques | | --- | --- | --- | --- | | BatchSize | N | 100 | Maximum : 10 000. | | DestinationConfig | N | N/A | [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md) | | Activé | N | True | | | FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) | | FunctionName | Y | N/A | | | KMSKeyArn | N | N/A | [Chiffrement des critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption) | | MaximumBatchingWindowInSeconds | N | 500 ms | [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) | | ProvisionedPollersConfig | N | `MinimumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 1 `MaximumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 200 `PollerGroupName`: N/A | [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode) | | SelfManagedEventSource | Y | N/A | Liste des agents Kafka. Peut définir uniquement sur Create (Créer) | | SelfManagedKafkaEventSourceConfig | N | Contient le ConsumerGroupId champ qui prend par défaut une valeur unique. | Peut définir uniquement sur Create (Créer) | | SourceAccessConfigurations | N | Pas d’informations d’identification | Informations sur le VPC ou informations d’authentification pour le cluster Pour SASL\$1PLAIN, défini sur BASIC\$1AUTH | | StartingPosition | Y | N/A | AT\$1TIMESTAMP, TRIM\$1HORIZON ou DERNIER Peut définir uniquement sur Create (Créer) | | StartingPositionTimestamp | N | N/A | Obligatoire s'il StartingPosition est défini sur AT\$1TIMESTAMP | | Étiquettes | N | N/A | [Utilisation des balises dans les mappages des sources d’événements](tags-esm.md) | | Rubriques | Y | N/A | Nom du sujet Peut définir uniquement sur Create (Créer) | **Note** Lorsque vous spécifiez un`PollerGroupName`, plusieurs ESMs au sein d'un même Amazon VPC peuvent partager la capacité de l'Event Poller Unit (EPU). Vous pouvez utiliser cette option pour optimiser les coûts du mode provisionné pour votre ESMs. Exigences relatives au regroupement ESM : ESMs doit se trouver dans le même Amazon VPC Maximum de 100 ESMs par groupe de sondeurs Le nombre maximum de sondeurs agrégés pour l'ensemble ESMs d'un groupe ne peut pas dépasser 2 000 Vous pouvez le mettre `PollerGroupName` à jour pour déplacer un ESM vers un autre groupe, ou supprimer un ESM d'un groupe en le définissant `PollerGroupName` sur une chaîne vide (« »).