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 Amazon MSK [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) est un service entièrement géré qui vous permet de créer et d’exécuter des applications qui utilisent Apache Kafka pour traiter des données en streaming. Amazon MSK simplifie la configuration, la mise à l’échelle et la gestion des clusters Kafka. Amazon MSK facilite également la configuration de votre application pour plusieurs zones de disponibilité et pour des raisons de sécurité avec Gestion des identités et des accès AWS (IAM). Ce chapitre explique comment utiliser un cluster Amazon MSK en tant que source d’événements pour votre fonction Lambda. Le processus général d’intégration d’Amazon MSK à Lambda comprend les étapes suivantes : 1. **[Configuration du cluster et du réseau](with-msk-cluster-network.md)** : configurez d’abord votre [cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html). Cela inclut la configuration réseau correcte pour permettre à Lambda d’accéder à votre cluster. 1. **[Configuration du mappage des sources d’événements](with-msk-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 Amazon MSK à votre fonction. 1. **[Configuration de la fonction et des autorisations](with-msk-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). **Note** Vous pouvez désormais créer et gérer vos mappages de sources d'événements Amazon MSK directement depuis la console Lambda ou Amazon MSK. Les deux consoles offrent la possibilité de gérer automatiquement la configuration des autorisations de rôle d'exécution Lambda nécessaires pour un processus de configuration plus rationalisé. Pour des exemples expliquant comment configurer une intégration Lambda avec un cluster Amazon MSK, consultez les sections [Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda](services-msk-tutorial.md) Utilisation d'[Amazon MSK comme source d'événements AWS Lambda sur le blog AWS Compute et Intégration d'](https://aws.amazon.com/blogs/compute/using-amazon-msk-as-an-event-source-for-aws-lambda/)[Amazon MSK Lambda dans les Amazon MSK](https://amazonmsk-labs.workshop.aws/en/msklambda.html) Labs. **Topics** + [Exemple d’évènement](#msk-sample-event) + [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md) + [Configuration des autorisations Lambda pour les mappages de sources d'événements Amazon MSK](with-msk-permissions.md) + [Configuration de source d’événements Amazon MSK pour Lambda](with-msk-configure.md) + [Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda](services-msk-tutorial.md) ## Exemple d’évènement Lambda envoie le lot de messages dans le paramètre d’événement quand il invoque votre fonction. La charge utile d’un événement contient un tableau de messages. Chaque élément de tableau contient des détails de la rubrique Amazon MSK et un identifiant de partition, ainsi qu’un horodatage et un message codé en base 64. ``` { "eventSource":"aws:kafka", "eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2", "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 Amazon MSK et de votre réseau Amazon VPC pour Lambda Pour connecter votre AWS Lambda fonction à votre cluster Amazon MSK, vous devez configurer correctement votre cluster et l'[Amazon Virtual Private Cloud (VPC) dans lequel il](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) réside. Cette page décrit comment configurer votre cluster et votre VPC. Si votre cluster et votre VPC sont déjà correctement configurés, consultez [Configuration de source d’événements Amazon MSK pour Lambda](with-msk-configure.md) pour configurer le mappage des sources d’événements. **Topics** + [Présentation des exigences de configuration réseau pour les intégrations Lambda et MSK](#msk-network-requirements) + [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway) + [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink) ## Présentation des exigences de configuration réseau pour les intégrations Lambda et MSK La configuration réseau requise pour une intégration Lambda et MSK dépend de l’architecture réseau de votre application. Trois ressources principales sont impliquées dans cette intégration : le cluster Amazon MSK, la fonction Lambda et le mappage des sources d’événements Lambda. Chacune de ces ressources réside dans un VPC différent : + Votre cluster Amazon MSK réside généralement dans un sous-réseau privé d’un VPC que vous gérez. + Votre fonction Lambda réside dans un VPC AWS géré appartenant à Lambda. + Le mappage de votre source d'événements Lambda réside dans un autre VPC AWS géré appartenant à Lambda, distinct du VPC qui contient votre fonction. Le [mappage des sources d’événements](invocation-eventsourcemapping.md) est la ressource intermédiaire entre le cluster MSK et la fonction Lambda. Le mappage des sources d’événements effectue deux tâches principales. Tout d’abord, il interroge votre cluster MSK à la recherche de nouveaux messages. Ensuite, il invoque votre fonction Lambda avec ces messages. Ces trois ressources étant différentes VPCs, les opérations d'interrogation et d'appel nécessitent des appels réseau inter-VPC. Les exigences de configuration réseau pour votre mappage des sources d’événements varient selon qu’il utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) ou le mode à la demande, comme le montre le schéma suivant : ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-esm-network-overview.png) La façon dont le mappage des sources d’événements Lambda interroge votre cluster MSK à la recherche de nouveaux messages est la même dans les deux modes. Pour établir une connexion entre votre mappage des sources d’événements et votre cluster MSK, Lambda crée une [ENI Hyperplane](configuration-vpc.md#configuration-vpc-enis) (ou réutilise une ENI existante, si disponible) dans votre sous-réseau privé afin d’établir une connexion sécurisée. Comme illustré dans le schéma, cette ENI Hyperplane utilise la configuration du sous-réseau et du groupe de sécurité de votre cluster MSK, et non votre fonction Lambda. Après avoir interrogé le message du cluster, la façon dont Lambda invoque votre fonction est différente dans chaque mode : + En mode provisionné, Lambda gère automatiquement la connexion entre le VPC du mappage des sources d’événements et le VPC de la fonction. Vous n’avez donc pas besoin de composants de mise en réseau supplémentaires pour invoquer votre fonction avec succès. + En mode à la demande, votre mappage des sources d’événements Lambda invoque votre fonction via un chemin passant par votre VPC géré par le client. Pour cette raison, vous devez configurer soit une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le sous-réseau public de votre VPC, soit des points de terminaison [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) dans le sous-réseau privé du VPC qui fournissent un accès à Lambda, [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) et éventuellement [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). La configuration correcte de l’une ou l’autre de ces options permet d’établir une connexion entre votre VPC et le VPC d’environnement d’exécution géré par Lambda, ce qui est nécessaire pour invoquer votre fonction. Une passerelle NAT permet aux ressources de votre sous-réseau privé d’accéder à l’Internet public. L'utilisation de cette configuration signifie que votre trafic traverse Internet avant d'appeler la fonction Lambda. AWS PrivateLink les points de terminaison permettent aux sous-réseaux privés de se connecter en toute sécurité à AWS des services ou à d'autres ressources VPC privées sans passer par l'Internet public. Consultez [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway) ou [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink) pour en savoir plus sur la façon de configurer ces ressources. Jusqu’à présent, nous avons supposé que votre cluster MSK résidait dans un sous-réseau privé au sein de votre VPC, ce qui est le cas le plus courant. Toutefois, même si votre cluster MSK se trouve dans un sous-réseau public au sein de votre VPC, vous devez configurer des points de terminaison AWS PrivateLink pour permettre une connexion sécurisée. Le tableau suivant résume les exigences de configuration réseau en fonction de la façon dont vous configurez votre cluster MSK et du mappage des sources d’événements Lambda : | Emplacement du cluster MSK (dans un VPC géré par le client) | Mode de mise à l’échelle du mappage des sources d’événements Lambda | Configuration réseau requise | | --- | --- | --- | | Sous-réseau privé | Mode de capacité à la demande | Passerelle NAT (dans le sous-réseau public de votre VPC) ou AWS PrivateLink points de terminaison (dans le sous-réseau privé de votre VPC) pour permettre l'accès à Lambda, et AWS STSéventuellement à Secrets Manager. | | Public subnet | Mode de capacité à la demande | AWS PrivateLink points de terminaison (dans le sous-réseau public de votre VPC) pour permettre l'accès à Lambda et, éventuellement AWS STS, à Secrets Manager. | | Sous-réseau privé | Mode alloué | Aucune | | Public subnet | Mode alloué | Aucune | En outre, les groupes de sécurité associés à votre cluster MSK doivent autoriser le trafic sur les bons ports. Vérifiez que les règles de groupe de sécurité suivantes sont configurées : + **Règles entrantes** : autorisez tout le trafic sur le port d’agent par défaut. Le port utilisé par MSK dépend du type d’authentification sur le cluster : `9098` pour l’authentification IAM, `9096` pour SASL/SCRAM et `9094` pour TLS. 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 de sortie** : autorisez tout le trafic sur le port `443` pour les destinations externes si votre fonction doit communiquer avec d'autres AWS services. Vous pouvez également utiliser une règle de groupe de sécurité à référencement automatique pour limiter l'accès au courtier si vous n'avez pas besoin de communiquer avec d'autres AWS services. + **Règles entrantes de point de terminaison Amazon VPC** :si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité du cluster. ## Configuration d’une passerelle NAT pour une source d’événements MSK Vous pouvez configurer une passerelle NAT pour permettre à votre mappage des sources d’événements d’interroger les messages de votre cluster et d’invoquer la fonction via un chemin à travers votre VPC. Cela n’est nécessaire que si votre mappage des sources d’événements utilise le mode à la demande et que votre cluster réside dans un sous-réseau privé de votre VPC. Si votre cluster réside dans un sous-réseau public de votre VPC, ou si le mappage des sources d’événements utilise le mode provisionné, vous n’avez pas besoin de configurer de passerelle NAT. Une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) permet aux ressources d’un sous-réseau privé d’accéder à l’Internet public. Si vous avez besoin d’une connectivité privée à Lambda, consultez plutôt [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink). Après avoir configuré votre passerelle NAT, vous devez configurer les tables de routage appropriées. Cela permet au trafic provenant de votre sous-réseau privé d’être acheminé vers l’Internet public via la passerelle NAT. ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-NAT-Gateway.png) Les étapes suivantes vous guident dans la mise en réseau d’une passerelle NAT à l’aide de la console. Si nécessaire, répétez ces étapes pour chaque zone de disponibilité (AZ). **Configurer une passerelle NAT et un routage approprié (console)** 1. Suivez les étapes de [Créer une passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html), en notant ce qui suit : + Les passerelles NAT doivent toujours résider dans un sous-réseau public. Créez des passerelles NAT avec une [connectivité publique](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). + Si votre cluster MSK est répliqué sur plusieurs AZs, créez une passerelle NAT par AZ. Par exemple, dans chaque AZ, votre VPC doit avoir un sous-réseau privé contenant votre cluster et un sous-réseau public contenant votre passerelle NAT. Pour une configuration avec trois AZs, vous aurez trois sous-réseaux privés, trois sous-réseaux publics et trois passerelles NAT. 1. Après avoir créé votre passerelle NAT, ouvrez la [console Amazon VPC](https://console.aws.amazon.com/vpc/) et choisissez **Tables de routage** dans le menu de gauche. 1. Choisissez **Créer une table de routage**. 1. Associez cette table de routage au VPC contenant votre cluster MSK. Vous pouvez éventuellement saisir un nom pour votre table de routage. 1. Choisissez **Créer une table de routage**. 1. Choisissez la table de routage que vous venez de créer. 1. Sur l’onglet **Associations de sous-réseau**, choisissez **Modifier les associations de sous-réseau**. + Associez cette table de routage au sous-réseau privé contenant votre cluster MSK. 1. Choisissez **Edit routes (Modifier des routes)**. 1. Choisissez **Ajouter une route** : 1. Pour **Destination**, choisissez `0.0.0.0/0`. 1. Pour **Cible**, choisissez **Passerelle NAT**. 1. Dans la zone de recherche, choisissez la passerelle NAT que vous avez créée à l’étape 1. Il doit s’agir de la passerelle NAT située dans la même AZ que le sous-réseau privé contenant votre cluster MSK (le sous-réseau privé que vous avez associé à cette table de routage à l’étape 6). 1. Sélectionnez **Enregistrer les modifications**. ## Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK Vous pouvez configurer des AWS PrivateLink points de terminaison pour interroger les messages de votre cluster et appeler la fonction via un chemin via votre VPC. Ces points de terminaison devraient permettre à votre cluster MSK d’accéder à ce qui suit : + Le service Lambda + [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) + Éventuellement le service [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). Il est nécessaire si le secret requis pour l’authentification du cluster est stocké dans Secrets Manager. La configuration des PrivateLink points de terminaison n'est requise que si le mappage des sources d'événements utilise le mode à la demande. Si votre mappage des sources d’événements utilise le mode provisionné, Lambda établit les connexions requises pour vous. PrivateLink les points de terminaison permettent un accès sécurisé et privé aux AWS services. AWS PrivateLink Vous pouvez également configurer une passerelle NAT afin de permettre à votre cluster MSK d’accéder à l’Internet public (voir [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway)). Une fois que vous avez configuré vos points de terminaison de VPC, votre cluster MSK devrait disposer d’un accès direct et privé à Lambda, STS et éventuellement Secrets Manager. ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-PrivateLink-Endpoints.png) Les étapes suivantes vous guident dans la configuration d'un PrivateLink point de terminaison à l'aide de la console. Si nécessaire, répétez ces étapes pour chaque point de terminaison (Lambda, STS, Secrets Manager). **Pour configurer les PrivateLink points de terminaison VPC (console)** 1. Ouvrez la [console Amazon VPC](https://console.aws.amazon.com/vpc/) et choisissez **Points de terminaison** dans le menu de gauche. 1. Choisissez **Créer un point de terminaison**. 1. Vous pouvez éventuellement saisir un nom pour votre point de terminaison. 1. Dans **Type**, sélectionnez **Services AWS **. 1. Sous **Services**, commencez à saisir le nom du service. Par exemple, pour créer un point de terminaison pour la connexion à Lambda, saisissez `lambda` dans le champ de recherche. 1. Dans les résultats, vous devriez voir le point de terminaison de service dans la région actuelle. Par exemple, dans la région USA Est (Virginie du Nord), vous devriez voir `com.amazonaws.us-east-2.lambda`. Sélectionnez ce service. 1. Sous **Paramètres réseau**, sélectionnez le VPC qui contient votre cluster MSK. 1. Sous **Sous-réseaux**, sélectionnez le cluster dans lequel AZs se trouve votre cluster MSK. + Pour chaque AZ, sous **ID de sous-réseau**, choisissez le sous-réseau privé contenant votre cluster MSK. 1. Sous **Groupes de sécurité**, sélectionnez les groupes de sécurité associés à votre cluster MSK. 1. Choisissez **Créer un point de terminaison**. 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. Par exemple, pour votre point de terminaison Secrets Manager, vous pouvez modifier sa politique de sorte qu’il autorise uniquement le rôle d’exécution de votre fonction à accéder au secret. **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" } ] } ``` Pour les points de terminaison Lambda AWS STS et Lambda, vous pouvez limiter le principal appelant au principal de service Lambda. Cependant, assurez-vous d’utiliser `"Resource": "*"` dans ces politiques. **Example Politique de point de terminaison 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 Lambda pour les mappages de sources d'événements Amazon MSK Pour accéder au cluster Amazon MSK, votre fonction et votre mappage des sources d’événements ont besoin d’autorisations pour effectuer diverses actions de l’API Amazon MSK. Ajoutez ces autorisations au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Si vos utilisateurs ont besoin de l’accès, ajoutez les autorisations requises à la stratégie d’identité de l’utilisateur ou du rôle correspondant. La politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) contient les autorisations minimales requises pour les mappages de sources d'événements Amazon MSK Lambda. Pour simplifier le processus d'autorisation, vous pouvez : + Associez la politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) à votre rôle d'exécution. + Laissez la console Lambda générer les autorisations pour vous. Lorsque vous [créez un mappage de source d'événement Amazon MSK dans la console](msk-esm-create.md#msk-console), Lambda évalue votre rôle d'exécution et vous avertit si des autorisations sont manquantes. Choisissez **Générer des autorisations** pour mettre à jour automatiquement votre rôle d'exécution. Cela ne fonctionne pas si vous avez créé ou modifié manuellement vos politiques de rôle d'exécution, ou si les politiques sont associées à plusieurs rôles. Notez que des autorisations supplémentaires peuvent toujours être requises dans votre rôle d'exécution lorsque vous utilisez des fonctionnalités avancées telles que la [destination en cas d'échec](kafka-on-failure.md) ou le [registre des AWS Glue schémas](services-consume-kafka-events.md). **Topics** + [Autorisations requises](#msk-required-permissions) + [Autorisations facultatives](#msk-optional-permissions) ## Autorisations requises Votre rôle d'exécution de fonction Lambda doit disposer des autorisations requises suivantes pour les mappages de sources d'événements Amazon MSK. Ces autorisations sont incluses dans la politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html). ### CloudWatch Autorisations de journalisation Les autorisations suivantes permettent à Lambda de créer et de stocker des journaux dans Amazon CloudWatch Logs. + [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 du cluster MSK Les autorisations suivantes permettent à Lambda d'accéder à votre cluster Amazon MSK en votre nom : + [Kafka : DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html) + [Source : V2 DescribeCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html) + [Kafka : GetBootstrapBrokers](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html) Nous recommandons d'utiliser [kafka : DescribeCluster V2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html) au lieu de [kafka](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html) :. DescribeCluster L'autorisation v2 fonctionne à la fois avec les clusters Amazon MSK provisionnés et sans serveur. Vous n'avez besoin que d'une de ces autorisations dans votre politique. ### Autorisations VPC Les autorisations suivantes permettent à Lambda de créer et de gérer des interfaces réseau lors de la connexion à votre cluster Amazon MSK : + [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) ## Autorisations facultatives Votre fonction Lambda peut également nécessiter ces autorisations pour : + Accédez à des clusters Amazon MSK multicomptes. Pour les mappages de sources d'événements entre comptes, vous avez besoin de [kafka : DescribeVpcConnection](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connection-arn.html) dans le rôle d'exécution. Un directeur IAM qui crée un mappage de sources d'événements entre comptes a besoin de [Kafka](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connections.html) :. ListVpcConnections + Accédez à votre secret SCRAM si vous utilisez l’[authentification SASL/SCRAM](msk-cluster-auth.md#msk-sasl-scram). Cela permet à votre fonction d’utiliser un nom d’utilisateur et un mot de passe pour se connecter à Kafka. + Décrivez le secret de votre Secrets Manager, si vous utilisez l' SASL/SCRAM [authentification mTLS](msk-cluster-auth.md#msk-mtls). Cela permet à votre fonction de récupérer les informations d’identification ou les certificats nécessaires pour des connexions sécurisées. + Accédez à votre clé gérée par le AWS KMS client, si votre AWS Secrets Manager secret est chiffré à l'aide d'une clé gérée par le AWS KMS client. + Accédez aux secrets de votre registre de schémas, si vous utilisez un registre de schémas avec authentification : + Pour le registre des AWS Glue schémas : les besoins `glue:GetRegistry` et `glue:GetSchemaVersion` les autorisations de votre fonction. Elles permettent à votre fonction de rechercher et d’utiliser les règles de format de message stockées dans AWS Glue. + Pour le [registre de schémas Confluent](https://docs.confluent.io/platform/current/schema-registry/security/index.html) avec `BASIC_AUTH` ou `CLIENT_CERTIFICATE_TLS_AUTH` : votre fonction a besoin de l’autorisation `secretsmanager:GetSecretValue` pour accéder au secret contenant les informations d’authentification. Cela permet à votre fonction de récupérer les username/password certificats nécessaires pour accéder au registre des schémas Confluent. + Pour les certificats CA privés : votre fonction a besoin de l'GetSecretValue autorisation secretsmanager : pour le secret contenant le certificat. Cela permet à votre fonction de vérifier l’identité des registres de schémas qui utilisent des certificats personnalisés. + Accédez aux groupes de consommateurs du cluster Kafka et interrogez les messages depuis le sujet, si vous utilisez l'authentification IAM pour le mappage des sources d'événements. Cela correspond aux autorisations requises suivantes : + [kafka : ListScramSecrets](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html) - Permet de répertorier les secrets SCRAM pour l'authentification Kafka + [secretsmanager : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) - Permet de récupérer des secrets depuis Secrets Manager + [KMS:Decrypt - Permet le déchiffrement](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) de données cryptées en utilisant AWS KMS + [glue : GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html) - Autorise l'accès au registre des AWS Glue schémas + [glue : GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html) - Permet de récupérer des versions de schéma spécifiques à partir du registre des AWS Glue schémas + [Kafka-Cluster:connect - Accorde l'autorisation de se connecter](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) et de s'authentifier auprès du cluster + [kafka-cluster : AlterGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de rejoindre des groupes sur un cluster, équivalent à l'ACL READ GROUP d'Apache Kafka + [kafka-cluster : DescribeGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de décrire les groupes d'un cluster, équivalent à l'ACL DESCRIBE GROUP d'Apache Kafka + [kafka-cluster : DescribeTopic](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de décrire les sujets d'un cluster, équivalent à l'ACL DESCRIBE TOPIC d'Apache Kafka + [kafka-cluster : ReadData](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de lire les données des rubriques d'un cluster, équivalent à l'ACL READ TOPIC d'Apache Kafka En outre, si vous souhaitez envoyer des enregistrements d’invocations ayant échoué vers une destination en cas d’échec, vous devez disposer des autorisations suivantes en fonction du type de destination : + Pour les destinations Amazon SQS : [sqs : SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) - Permet d'envoyer des messages à une file d'attente Amazon SQS + Pour les destinations Amazon SNS : [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) : permet de publier des messages sur une rubrique Amazon SNS + Pour les destinations du compartiment Amazon S3 : [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) et [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBucket.html) - Permet d'écrire et de répertorier des objets dans un compartiment Amazon S3 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 source d’événements Amazon MSK pour Lambda Pour utiliser un cluster Amazon MSK comme 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 Amazon MSK. Cette page suppose que vous avez déjà correctement configuré votre cluster MSK et l’instance [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) dans lequel il réside. Si vous devez configurer votre cluster ou VPC, consultez [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md). Pour configurer le comportement des nouvelles tentatives afin de gérer les erreurs, consultez[Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md). **Topics** + [Utilisation d’un cluster Amazon MSK en tant que source d’événement](#msk-esm-overview) + [Configuration des méthodes d'authentification du cluster Amazon MSK dans Lambda](msk-cluster-auth.md) + [Création d’un mappage des sources d’événements Lambda pour une source d’événements Amazon MSK](msk-esm-create.md) + [Création de mappages de sources d’événements entre comptes dans Lambda](msk-cross-account.md) + [Tous les paramètres de configuration des sources d’événements Amazon MSK dans Lambda](msk-esm-parameters.md) ## Utilisation d’un cluster Amazon MSK en tant que 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 du cluster Amazon MSK dans Lambda Lambda doit être autorisé à accéder à votre cluster Amazon MSK, à récupérer des enregistrements et à effectuer d’autres tâches. Amazon MSK prend en charge plusieurs méthodes d’authentification auprès de votre cluster MSK. **Topics** + [Accès non authentifié](#msk-unauthenticated) + [Authentification SASL/SCRAM](#msk-sasl-scram) + [Authentification TLS mutuelle](#msk-mtls) + [Authentification IAM](#msk-iam-auth) + [Comment Lambda choisit un courtier bootstrap](#msk-bootstrap-brokers) ## Accès non authentifié Si aucun client n’accède au cluster via Internet, vous pouvez utiliser un accès non authentifié. ## Authentification SASL/SCRAM Lambda prend en charge [l'authentification simple et l'authentification SASL/SCRAM (Security Layer/Salted Challenge Response Authentication Mechanism)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html), avec la fonction de hachage SHA-512 et le chiffrement TLS (Transport Layer Security). Pour que Lambda se connecte au cluster, stockez les informations d’identification d’authentification (nom d’utilisateur et mot de passe) dans un secret Secrets Manager, et référencez ce secret lors de la configuration de votre mappage des sources d’événements. Pour plus d’informations sur l’utilisation de Secrets Manager, consultez [Authentification par informations d’identification avec Secrets Manager](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*. **Note** Amazon MSK ne prend pas en charge SASL/PLAIN l'authentification. ## 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 ce dernier vérifie le client. Le serveur envoie également un certificat au client pour que ce dernier vérifie le serveur. Pour les intégrations Amazon MSK avec Lambda, votre cluster MSK agit en tant que serveur et Lambda en tant que client. + Pour que Lambda puisse vérifier votre cluster MSK, vous devez configurer un certificat client en tant que secret dans Secrets Manager et référencer ce certificat dans votre configuration de mappage des sources d’événements. Le certificat client doit être signé par une autorité de certification (CA) située dans le magasin d’approbations du serveur. + Le cluster MSK envoie également un certificat de serveur à Lambda. Le certificat du serveur doit être signé par une autorité de certification (CA) dans le AWS trust store. Amazon MSK ne prend pas en charge les certificats de serveur autosignés. Tous les courtiers d'Amazon MSK utilisent des [certificats publics](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html) signés par [Amazon Trust Services CAs](https://www.amazontrust.com/repository/), auxquels Lambda fait confiance par défaut. ### Configuration du secret mTLS 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, vous devez inclure 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-----" } ``` Pour plus d’informations sur le protocole mTLS pour Amazon MSK et des instructions sur la génération d’un certificat client, consultez [Authentification de client TLS mutuel pour Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*. ## Authentification IAM Vous pouvez utiliser Gestion des identités et des accès AWS (IAM) pour authentifier l'identité des clients qui se connectent au cluster MSK. Avec l’authentification IAM, Lambda s’appuie sur les autorisations du rôle d’exécution de votre fonction pour se connecter au cluster, récupérer des enregistrements et effectuer d’autres actions requises.[Définition des autorisations de fonction Lambda avec un rôle d’exécution](lambda-intro-execution-role.md) Pour un exemple de politique contenant les autorisations nécessaires, consultez [Créer des politiques d’autorisation pour le rôle IAM](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) dans le *Guide du développeur Amazon Managed Streaming pour Apache Kafka*. Si l’authentification IAM est active sur votre cluster MSK et que vous ne fournissez pas de secret, Lambda utilise automatiquement l’authentification IAM par défaut. Pour de plus amples informations sur l’authentification IAM dans Amazon MSK, veuillez consulter [Contrôle d’accès IAM](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html). ## Comment Lambda choisit un courtier bootstrap Lambda choisit un [courtier d’amorçage](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) en fonction des méthodes d’authentification disponibles sur votre cluster, et si vous fournissez un secret pour l’authentification. Si vous fournissez un secret pour les mTLS ou SASL/SCRAM, Lambda choisit automatiquement cette méthode d’authentification. Si vous ne e faites pas, Lambda sélectionne la méthode d’authentification la plus puissante active sur votre cluster. Voici l’ordre de priorité dans lequel Lambda sélectionne un courtier, de l’autorisation la plus forte à la plus faible : + MTLs (secret fourni pour les mTLS) + SASL/SCRAM (secret provided for SASL/SCRAM) + SASL IAM (aucun secret fourni et authentification IAM active) + TLS non authentifié (aucun secret fourni et authentification IAM non active) + Texte brut (aucun secret n’est fourni, et l’authentification IAM et le TLS non authentifié ne sont pas actifs) **Note** Si Lambda ne parvient pas à se connecter au type de courtier le plus sécurisé, Lambda n’essaie pas de se connecter à un type de courtier différent (plus faible). Si vous souhaitez que Lambda choisisse un type de courtier plus faible, désactivez toutes les méthodes d’authentification plus puissantes sur votre cluster. # Création d’un mappage des sources d’événements Lambda pour une source d’événements Amazon MSK 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/). **Note** Lorsque vous créez le mappage des sources d’événements, Lambda crée une [ENI Hyperplane](configuration-vpc.md#configuration-vpc-enis) dans le sous-réseau privé qui contient votre cluster MSK, ce qui permet à Lambda d’établir une connexion sécurisée. Cette ENI Hyperplane utilise la configuration du sous-réseau et du groupe de sécurité de votre cluster MSK, et non votre fonction Lambda. Les étapes de console suivantes ajoutent un cluster Amazon MSK comme déclencheur pour votre fonction Lambda. En arrière-plan, cela crée une ressource de mappage des sources d’événements. **Pour ajouter un déclencheur Amazon MSK à votre fonction Lambda (console)** 1. Ouvrez la [page Fonction](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda. 1. Choisissez le nom de la fonction Lambda pour laquelle vous souhaitez ajouter un déclencheur Amazon MSK. 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), choisissez **MSK**. 1. Pour spécifier les détails de votre cluster Kafka, procédez comme suit : 1. Pour **MSK cluster (Cluster MSK)**, sélectionnez votre cluster. 1. Dans **Nom de la rubrique**, donnez un nom à la rubrique Kafka dont vous souhaitez consommer les messages. 1. Pour **l’identifiant de groupe de consommateurs**, entrez l’identifiant d’un groupe de consommateurs Kafka à rejoindre, le cas échéant. Pour de plus amples informations, veuillez consulter [ID de groupe de consommateurs personnalisable dans Lambda](kafka-consumer-group-id.md). 1. Pour **Authentification du cluster**, effectuez les configurations nécessaires. Pour plus d'informations sur l'authentification du cluster, consultez [Configuration des méthodes d'authentification du cluster Amazon MSK dans Lambda](msk-cluster-auth.md). + Activez **Utiliser l’authentification** si vous souhaitez que Lambda effectue l’authentification auprès de votre cluster MSK lors de l’établissement d’une connexion. L’authentification est recommandée. + Si vous utilisez l’authentification, dans **Méthode d’authentification**, choisissez la méthode d’authentification à utiliser. + Si vous utilisez l’authentification, pour **Clé Secrets Manager**, choisissez la clé Secrets Manager qui contient les informations d’identification d’authentification nécessaires pour accéder à votre cluster. 1. Sous **Configuration des sondeurs d’événements**, effectuez les configurations nécessaires. + Choisissez **Activer le déclencheur** pour activer le déclencheur immédiatement après sa création. + Choisissez si vous souhaitez **Configurer le mode provisionné** pour votre mappage des sources d’événements. Pour de plus amples informations, veuillez consulter [Modes de mise à l’échelle des sondeurs d’événements Apache Kafka dans Lambda](kafka-scaling-modes.md). + 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. + Dans **Position de départ**, choisissez la façon dont vous souhaitez que Lambda commence à lire à partir de votre flux. Pour de plus amples informations, veuillez consulter [Positions de départ des interrogations et flux Apache Kafka dans Lambda](kafka-starting-positions.md). 1. Sous **Traitement par lots**, effectuez les configurations nécessaires. Pour plus d’informations sur la mise en lots, consultez [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). 1. Pour **Batch size (Taille de lot)**, entrez le nombre maximum d’enregistrements à recevoir dans un même lot. 1. Pour **Batch window**, veuillez saisir le nombre maximal de secondes nécessaires à Lambda pour collecter des enregistrements avant d’invoquer la fonction. 1. Sous **Filtrage**, effectuez les configurations nécessaires. Pour plus d’informations sur le filtrage, veuillez consulter la rubrique [Filtrage des événements provenant d’Amazon MSK et sources d’événements Apache Kafka autogéré](kafka-filtering.md). + Pour **Critères de filtre**, ajoutez des définitions de critères de filtre pour déterminer s’il faut ou non traiter un événement. 1. Sous **Gestion des échecs**, effectuez les configurations nécessaires. Pour plus d’informations sur la gestion des échecs, consultez [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md). + Pour **Destination en cas d’échec**, spécifiez l’ARN de votre destination en cas d’échec. 1. Pour **Balises**, saisissez les balises à associer à ce mappage des sources d’événements. 1. Pour créer le déclencheur, choisissez **Add** (Ajouter). Vous pouvez également créer le mappage des sources d'événements à l'aide de la AWS CLI avec la [ create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande. L’exemple suivant crée un mappage des sources d’événements pour associer la fonction Lambda `my-msk-function` à la rubrique `AWSKafkaTopic`, en commençant par le message `LATEST`. Cette commande utilise également l'[SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet pour demander à Lambda d'[utiliser](msk-cluster-auth.md#msk-sasl-scram) l'authentification SASL/SCRAM lors de la connexion au cluster. ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function --source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]' ``` Si le cluster utilise l'[authentification mTLS](msk-cluster-auth.md#msk-mtls), incluez un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui le spécifie `CLIENT_CERTIFICATE_TLS_AUTH` et un ARN de clé Secrets Manager. En voici un exemple dans la commande suivante : ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function --source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]' ``` Lorsque le cluster utilise l'[authentification IAM](msk-cluster-auth.md#msk-iam-auth), vous n'avez pas besoin d'[ SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet. En voici un exemple dans la commande suivante : ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function ``` # Création de mappages de sources d’événements entre comptes dans Lambda Vous pouvez utiliser la [connectivité privée multi-VPC](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html) pour connecter une fonction Lambda à un cluster MSK provisionné dans un autre Compte AWS. La connectivité multi-VPC utilise AWS PrivateLink, ce qui permet de maintenir tout le trafic sur le AWS réseau. **Note** Vous ne pouvez pas créer de mappages de sources d’événements entre comptes pour les clusters MSK sans serveur. Pour créer un mappage des sources d’événements entre comptes, vous devez d’abord [configurer la connectivité multi-VPC pour le cluster MSK](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-cluster-owner-action-turn-on). Lorsque vous créez le mappage des sources d’événements, utilisez l’ARN de connexion VPC géré au lieu de l’ARN du cluster, comme indiqué dans les exemples suivants. Le [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)fonctionnement varie également en fonction du type d'authentification utilisé par le cluster MSK. **Example — Crée un mappage des sources d’événements entre comptes pour le cluster qui utilise l’authentification IAM** Lorsque le cluster utilise l'[authentification basée sur les rôles IAM](msk-cluster-auth.md#msk-iam-auth), vous n'avez pas besoin d'objet. [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) Exemple : ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function ``` **Example — Créez un mappage des sources d'événements entre comptes pour le cluster qui utilise l'authentification SASL/SCRAM** Si le cluster utilise l'[authentification SASL/SCRAM](msk-cluster-auth.md#msk-sasl-scram), vous devez inclure un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui spécifie `SASL_SCRAM_512_AUTH` et un ARN secret du Secrets Manager. Il existe deux manières d'utiliser les secrets pour les mappages de sources d'événements Amazon MSK entre comptes avec authentification : SASL/SCRAM + Créez un secret dans le compte de fonction Lambda et synchronisez-le avec le secret du cluster. [Créez une rotation](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) pour synchroniser les deux secrets. Cette option vous permet de contrôler le secret depuis le compte de fonction. + Utilisez le secret associé au cluster MSK. Ce secret doit autoriser l’accès intercompte au compte de la fonction Lambda. Pour plus d’informations, voir [Autorisations d’accéder aux secrets AWS Secrets Manager pour les utilisateurs d’un autre compte](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html). ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function \ --source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]' ``` **Example — Crée un mappage des sources d’événements entre comptes pour le cluster qui utilise l’authentification mTLS** Si le cluster utilise l'[authentification mTLS](msk-cluster-auth.md#msk-mtls), vous devez inclure un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui spécifie `CLIENT_CERTIFICATE_TLS_AUTH` et un ARN secret de Secrets Manager. Le secret peut être stocké dans le compte du cluster ou dans le compte de la fonction Lambda. ``` aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function \ --source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]' ``` # Tous les paramètres de configuration des sources d’événements Amazon MSK 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 à Amazon MSK, comme indiqué dans le tableau suivant. | Paramètre | Obligatoire | Par défaut | Remarques | | --- | --- | --- | --- | | AmazonManagedKafkaEventSourceConfig | N | Contient le ConsumerGroupId champ, dont la valeur par défaut est unique. | Peut définir uniquement sur Create (Créer) | | 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 | | | BisectBatchOnFunctionError | N | False | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) | | FunctionResponseTypes | N | N/A | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) | | MaximumRecordAgeInSeconds | N | -1 (infini) | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) | | MaximumRetryAttempts | N | -1 (infini) | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) | | EventSourceArn | Y | N/A | Peut définir uniquement sur Create (Créer) | | 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) | | SourceAccessConfigurations | N | Pas d’informations d’identification | Informations d’identification d’authentification SASL/SCRAM ou CLIENT\$1CERTIFICATE\$1TLS\$1AUTH (TLS mutuel) pour votre source d’événement | | 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 de rubrique Kafka 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 (« »). # Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda Dans ce tutoriel, vous exécuterez les étapes suivantes : + Créez une fonction Lambda dans le même AWS compte qu'un cluster Amazon MSK existant. + Configurer le réseau et l’authentification pour que Lambda communique avec Amazon MSK. + Configurer un mappage des sources d’événements Amazon MSK Lambda, qui exécute votre fonction Lambda lorsque des événements apparaissent dans la rubrique. Une fois ces étapes terminées, vous pouvez configurer une fonction Lambda pour traiter automatiquement les événements envoyés à Amazon MSK avec votre code Lambda personnalisé. **Que pouvez-vous faire avec cette fonctionnalité ?** **Exemple de solution : Utiliser un mappage des sources d’événements MSK pour fournir des résultats en direct à vos clients.** Imaginons le scénario suivant : votre entreprise héberge une application Web dans laquelle vos clients peuvent consulter des informations sur des événements en direct, tels que des matchs de sport. Les informations actualisées du jeu sont fournies à votre équipe via une rubrique Kafka sur Amazon MSK. Vous souhaitez concevoir une solution qui utilise les mises à jour issues de la rubrique MSK afin de fournir une vue actualisée de l’événement en direct aux clients au sein d’une application que vous développez. Vous avez opté pour l’approche de conception suivante : vos applications clientes communiqueront avec un dorsal sans serveur hébergé dans AWS. Les clients se connecteront via des sessions websocket à l'aide de l'API Amazon WebSocket API Gateway. Dans cette solution, vous avez besoin d’un composant qui lit les événements MSK, exécute une logique personnalisée pour préparer ces événements pour la couche application, puis transmet ces informations à l’API API Gateway. Vous pouvez implémenter ce composant en fournissant votre logique personnalisée dans une fonction Lambda, puis en l'appelant à l'aide d'un mappage de source d'événements AWS Lambda Amazon MSK. AWS Lambda Pour plus d'informations sur la mise en œuvre de solutions à l'aide de l'API Amazon WebSocket API Gateway, consultez les [WebSocket didacticiels](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-chat-app.html) sur les API dans la documentation d'API Gateway. ## Conditions préalables Un AWS compte avec les ressources préconfigurées suivantes : **Pour remplir ces prérequis, nous vous recommandons de suivre [Get started using Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/getting-started.html) dans la documentation Amazon MSK.** + Un cluster Amazon MSK. Consultez [Create an Amazon MSK cluster](https://docs.aws.amazon.com//msk/latest/developerguide/create-cluster.html) dans *Getting started using Amazon MSK*. + La configuration suivante : + Assurez-vous que l’**authentification basée sur les rôles IAM** est **Activée** dans les paramètres de sécurité de votre cluster. Cela améliore votre sécurité en limitant votre fonction Lambda à l’accès aux ressources Amazon MSK nécessaires uniquement. L’authentification basée sur les rôles IAM est activée par défaut sur les nouveaux clusters Amazon MSK. + Assurez-vous que l’**Accès public** est désactivé dans les paramètres réseau de votre cluster. Restreindre l’accès à Internet de votre cluster Amazon MSK améliore votre sécurité en limitant le nombre d’intermédiaires qui traitent vos données. L’accès public est activé par défaut sur les nouveaux clusters Amazon MSK. + Une rubrique Kafka dans votre cluster Amazon MSK à utiliser pour cette solution. Consultez [Create a topic](https://docs.aws.amazon.com//msk/latest/developerguide/create-topic.html) dans *Getting started using Amazon MSK*. + Un hôte administrateur Kafka configuré pour extraire les informations de votre cluster Kafka et envoyer des événements Kafka à votre rubrique à des fins de test, par exemple une instance Amazon EC2 sur laquelle la CLI d’administration Kafka et la bibliothèque IAM Amazon MSK sont installées. Consultez [Create a client machine](https://docs.aws.amazon.com//msk/latest/developerguide/create-client-machine.html) dans *Getting started using Amazon MSK*. Une fois que vous avez configuré ces ressources, collectez les informations suivantes à partir de votre AWS compte pour confirmer que vous êtes prêt à continuer. + Le nom de votre cluster Amazon MSK. Vous pouvez trouver cette information dans la console Amazon MSK. + L’UUID du cluster, qui fait partie de l’ARN de votre cluster Amazon MSK, que vous pouvez trouver dans la console Amazon MSK. Suivez les procédures décrites dans la rubrique [Listing clusters](https://docs.aws.amazon.com/msk/latest/developerguide/msk-list-clusters.html) de la documentation Amazon MSK pour trouver cette information. + Les groupes de sécurité associés à votre cluster Amazon MSK. Vous pouvez trouver cette information dans la console Amazon MSK. Dans les étapes suivantes, appelez-les vos*clusterSecurityGroups*. + L’ID du VPC Amazon contenant votre cluster Amazon MSK. Vous pouvez trouver cette information en identifiant les sous-réseaux associés à votre cluster Amazon MSK dans la console Amazon MSK, puis en identifiant le VPC Amazon associé au sous-réseau dans la console Amazon VPC. + Le nom de la rubrique Kafka utilisée dans votre solution. Vous pouvez trouver cette information en appelant votre cluster Amazon MSK à l’aide de la CLI `topics` Kafka depuis votre hôte administrateur Kafka. Pour plus d’informations sur la CLI de rubriques, consultez la section [Adding and removing topics](https://kafka.apache.org/documentation/#basic_ops_add_topic) dans la documentation Kafka. + Le nom d’un groupe de consommateurs pour votre rubrique Kafka, adapté à une utilisation par votre fonction Lambda. Ce groupe peut être créé automatiquement par Lambda. Vous n’avez donc pas besoin de le créer avec la CLI Kafka. Si vous devez gérer vos groupes de consommateurs, pour en savoir plus sur la CLI de groupes de consommateurs, consultez la rubrique [Managing Consumer Groups](https://kafka.apache.org/documentation/#basic_ops_consumer_group) dans la documentation Kafka. Les autorisations suivantes dans votre AWS compte : + L’autorisation de créer et de gérer une fonction Lambda. + L’autorisation de créer des politiques IAM et de les associer à votre fonction Lambda. + L’autorisation de créer des points de terminaison de VPC Amazon et de modifier la configuration réseau dans le VPC Amazon hébergeant votre cluster Amazon MSK. ### Installez le AWS Command Line Interface Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer. Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré. **Note** Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash. ## Configurer la connectivité réseau pour que Lambda communique avec Amazon MSK AWS PrivateLink À utiliser pour connecter Lambda et Amazon MSK. Pour ce faire, vous créez des points de terminaison de VPC Amazon d’interface dans la console Amazon VPC. Pour plus d’informations sur la configuration réseau, consultez [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md). Lorsqu’un mappage des sources d’événements Amazon MSK s’exécute pour le compte d’une fonction Lambda, il endosse le rôle d’exécution de la fonction Lambda. Ce rôle IAM autorise le mappage pour accéder aux ressources sécurisées par IAM, telles que votre cluster Amazon MSK. Bien que les composants partagent un rôle d’exécution, le mappage Amazon MSK et votre fonction Lambda ont des exigences de connectivité distinctes pour leurs tâches respectives, comme le montre le schéma suivant. ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/msk_tut_network.png) Votre mappage des sources d’événements appartient au groupe de sécurité de votre cluster Amazon MSK. Au cours de cette étape de mise en réseau, créez des points de terminaison de VPC Amazon à partir de votre VPC de cluster Amazon MSK pour connecter le mappage des sources d’événements aux services Lambda et STS. Sécurisez ces points de terminaison pour accepter le trafic provenant du groupe de sécurité de votre cluster Amazon MSK. Ajustez ensuite les groupes de sécurité du cluster Amazon MSK pour permettre au mappage des sources d’événements de communiquer avec le cluster Amazon MSK. Vous pouvez configurer les étapes suivantes à l’aide de l’ AWS Management Console. **Pour configurer les points de terminaison de VPC Amazon d’interface afin de connecter Lambda et Amazon MSK** 1. Créez un groupe de sécurité pour les points de terminaison Amazon VPC de votre interface*endpointSecurityGroup*, qui autorise le trafic TCP entrant sur 443 depuis. *clusterSecurityGroups* Suivez la procédure décrite dans la rubrique [Create a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) de la documentation Amazon EC2 pour créer un groupe de sécurité. Suivez ensuite la procédure décrite dans la rubrique [Add rules to a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) de la documentation Amazon EC2 pour ajouter les règles appropriées. **Créez un groupe de sécurité avec les informations suivantes :** Lorsque vous ajoutez vos règles de trafic entrant, créez une règle pour chaque groupe de sécurité dans*clusterSecurityGroups*. Pour chaque règle : + Dans le champ **Type**, sélectionnez **HTTPS**. + Pour **Source**, sélectionnez l'un des*clusterSecurityGroups*. 1. Créez un point de terminaison connectant le service Lambda au VPC Amazon qui contient votre cluster Amazon MSK. Suivez la procédure décrite dans [Create an interface endpoint](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html). **Créez un point de terminaison d’interface avec les informations suivantes :** + Dans **Nom du service**`com.amazonaws.regionName.lambda`, sélectionnez où *regionName* héberge votre fonction Lambda. + Pour **VPC**, sélectionnez le VPC Amazon contenant votre cluster Amazon MSK. + Pour les **groupes de sécurité***endpointSecurityGroup*, sélectionnez ceux que vous avez créés précédemment. + Pour **Sous-réseaux**, sélectionnez les sous-réseaux qui hébergent votre cluster Amazon MSK. + Pour **Politique**, fournissez le document de politique suivant, qui sécurise le point de terminaison afin qu’il soit utilisé par le principal de service Lambda pour l’action `lambda:InvokeFunction`. ``` { "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` + Assurez-vous que **Activer le nom DNS** reste défini. 1. Créez un point de terminaison connectant le AWS STS service au Amazon VPC contenant votre cluster Amazon MSK. Suivez la procédure décrite dans [Create an interface endpoint](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html). **Créez un point de terminaison d’interface avec les informations suivantes :** + Pour **Nom du service**, sélectionnez AWS STS. + Pour **VPC**, sélectionnez le VPC Amazon contenant votre cluster Amazon MSK. + Pour les **groupes de sécurité**, sélectionnez*endpointSecurityGroup*. + Pour **Sous-réseaux**, sélectionnez les sous-réseaux qui hébergent votre cluster Amazon MSK. + Pour **Politique**, fournissez le document de politique suivant, qui sécurise le point de terminaison afin qu’il soit utilisé par le principal de service Lambda pour l’action `sts:AssumeRole`. ``` { "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` + Assurez-vous que **Activer le nom DNS** reste défini. 1. Pour chaque groupe de sécurité associé à votre cluster Amazon MSK, c'est-à-dire dans*clusterSecurityGroups*, autorisez ce qui suit : + Autorisez tout le trafic TCP entrant et sortant sur le 9098 à tous*clusterSecurityGroups*, y compris à l'intérieur de celui-ci. + Autorisez tout le trafic TCP sortant sur le port 443. Une partie de ce trafic est autorisée par les règles des groupes de sécurité par défaut. Par conséquent, si votre cluster est attaché à un seul groupe de sécurité et que ce groupe possède des règles par défaut, il n’est pas nécessaire d’ajouter des règles. Pour ajuster les règles de groupe de sécurité, suivez les procédures décrites dans la rubrique [Add rules to a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) de la documentation Amazon EC2. **Ajoutez des règles à vos groupes de sécurité avec les informations suivantes :** + Pour chaque règle entrante ou sortante pour le port 9098, indiquez + Pour **Type**, sélectionnez **Custom TCP (TCP personnalisé)**. + Pour **Plage de ports**, indiquez 9098. + Pour **Source**, indiquez l'un des*clusterSecurityGroups*. + Pour chaque règle entrante pour le port 443, pour **Type**, sélectionnez **HTTPS**. ## Créer un rôle IAM pour que Lambda puisse lire un extrait de votre rubrique Amazon MSK Identifiez les exigences d’authentification que Lambda doit lire dans votre rubrique Amazon MSK, puis définissez-les dans une politique. Créez un rôle qui autorise Lambda à utiliser ces autorisations. *lambdaAuthRole* Autorisez les actions sur votre cluster Amazon MSK à l’aide d’actions IAM `kafka-cluster`. Autorisez ensuite Lambda à effectuer les actions Amazon MSK et Amazon `kafka` EC2 nécessaires pour découvrir et vous connecter à votre cluster Amazon MSK, ainsi que les actions permettant à Lambda de consigner CloudWatch ce qu'il a fait. **Pour décrire les exigences d’authentification pour que Lambda puisse lire depuis Amazon MSK** 1. Rédigez un document de politique IAM (un document JSON) qui permet à Lambda de lire un extrait de votre sujet Kafka dans votre cluster Amazon MSK en utilisant votre groupe de consommateurs Kafka. *clusterAuthPolicy* Lambda nécessite qu’un groupe de consommateurs Kafka soit défini lors de la lecture. Modifiez le modèle suivant pour l’aligner sur vos prérequis : ------ #### [ JSON ] **** ``` { "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:us-east-1:111122223333:cluster/mskClusterName/cluster-uuid", "arn:aws:kafka:us-east-1:111122223333:topic/mskClusterName/cluster-uuid/mskTopicName", "arn:aws:kafka:us-east-1:111122223333:group/mskClusterName/cluster-uuid/mskGroupName" ] } ] } ``` ------ Pour plus d’informations, consultez [Configuration des autorisations Lambda pour les mappages de sources d'événements Amazon MSK](with-msk-permissions.md). Lorsque vous rédigez votre politique : + Remplacez *us-east-1* et *111122223333* par le Région AWS et Compte AWS de votre cluster Amazon MSK. + Pour*mskClusterName*, indiquez le nom de votre cluster Amazon MSK. + Pour*cluster-uuid*, fournissez l'UUID dans l'ARN de votre cluster Amazon MSK. + Pour*mskTopicName*, indiquez le nom de votre sujet Kafka. + Pour*mskGroupName*, indiquez le nom de votre groupe de consommateurs Kafka. 1. Identifiez Amazon MSK, Amazon EC2 CloudWatch et les autorisations requises pour que Lambda découvre et connecte votre cluster Amazon MSK, puis enregistrez ces événements. La politique gérée `AWSLambdaMSKExecutionRole` définit de manière permissive les autorisations requises. Utilisez-la dans les étapes suivantes. Dans un environnement de production, évaluez `AWSLambdaMSKExecutionRole` pour restreindre votre politique de rôle d’exécution sur la base du principe du moindre privilège, puis rédigez une politique pour votre rôle qui remplace cette politique gérée. Pour plus d’informations sur le langage de politique IAM, consultez la [documentation IAM](https://docs.aws.amazon.com//iam/). Maintenant que vous avez rédigé votre document de politique, créez une politique IAM afin de pouvoir l’attacher à votre rôle. Pour ce faire, vous pouvez utiliser la console en suivant la procédure ci-dessous. **Pour créer une politique IAM à partir de votre document de politique** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de gauche, choisissez **Politiques**. 1. Choisissez **Create Policy** (Créer une politique). 1. Dans la section **Éditeur de politiques**, choisissez l’option **JSON**. 1. Coller*clusterAuthPolicy*. 1. Lorsque vous avez fini d’ajouter des autorisations à la politique, choisissez **Suivant**. 1. Sur la page **Vérifier et créer**, tapez un **Nom de politique** et une **Description** (facultative) pour la politique que vous créez. Vérifiez les **Autorisations définies dans cette politique** pour voir les autorisations accordées par votre politique. 1. Choisissez **Create policy** (Créer une politique) pour enregistrer votre nouvelle politique. Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) dans la documentation IAM. Maintenant que vous disposez des politiques IAM appropriées, créez un rôle et attachez-les à celui-ci. Pour ce faire, vous pouvez utiliser la console en suivant la procédure ci-dessous. **Pour créer un rôle d’exécution dans la console IAM** 1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM. 1. Choisissez **Créer un rôle**. 1. Sous **Trusted entity type** (Type d’entité approuvée), choisissez **service AWS **. 1. Sous **Cas d’utilisation**, choisissez **Lambda**. 1. Choisissez **Suivant**. 1. Sélectionnez les stratégies suivantes : + *clusterAuthPolicy* + `AWSLambdaMSKExecutionRole` 1. Choisissez **Suivant**. 1. Dans **Nom du rôle**, entrez *lambdaAuthRole* puis choisissez **Créer un rôle**. Pour de plus amples informations, veuillez consulter [Définition des autorisations de fonction Lambda avec un rôle d’exécution](lambda-intro-execution-role.md). ## Créer une fonction Lambda pour lire à partir de votre rubrique Amazon MSK Créez une fonction Lambda configurée pour utiliser votre rôle IAM. Vous pouvez enregistrer votre fonction Lambda à l’aide de la console. **Pour créer une fonction Lambda à l’aide de votre configuration d’authentification** 1. Ouvrez la console Lambda et choisissez **Créer une fonction** dans l’en-tête. 1. Sélectionnez **Créer à partir de zéro**. 1. Pour **Nom de la fonction**, saisissez un nom approprié de votre choix. 1. Pour **Environnement d’exécution**, choisissez la dernière version prise en charge (**Dernier pris en charge**) de `Node.js` pour utiliser le code fourni dans ce tutoriel. 1. Choisissez **Modifier le rôle d’exécution par défaut**. 1. Sélectionnez **Utiliser un rôle existant**. 1. Pour **Rôle existant**, sélectionnez*lambdaAuthRole*. Dans un environnement de production, vous devez généralement ajouter des politiques supplémentaires au rôle d’exécution de votre fonction Lambda afin de traiter intelligemment vos événements Amazon MSK. Pour plus d’informations sur l’ajout de politiques à votre rôle, consultez la section [Ajouter ou supprimer des autorisations d’identité](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) dans la documentation IAM. ## Création d’un mappage des sources d’événements pour votre fonction Lambda Votre mappage des sources d’événements Amazon MSK fournit au service Lambda les informations nécessaires pour invoquer votre fonction Lambda lorsque des événements Amazon MSK appropriés se produisent. Vous pouvez créer un mappage Amazon MSK à l’aide de la console. Créez un déclencheur Lambda, puis le mappage des sources d’événements est automatiquement configuré. **Pour créer un déclenceur Lambda (et un mappage des sources d’événements)** 1. Accédez à la page de présentation de votre fonction Lambda. 1. Dans la section de présentation de la fonction, choisissez **Ajouter un déclencheur** en bas à gauche. 1. Dans le menu déroulant **Sélectionner une source**, sélectionnez **Amazon MSK**. 1. Ne configurez pas l’**authentification**. 1. Pour **Cluster MSK**, sélectionnez le nom de votre cluster. 1. Pour **Taille de lot**, saisissez 1. Cette étape facilite le test de cette fonctionnalité. Elle ne constitue pas une valeur idéale en production. 1. Pour **Nom de la rubrique**, indiquez le nom de votre rubrique Kafka. 1. Pour **ID du groupe de consommateurs**, indiquez l’ID de votre groupe de consommateurs Kafka. ## Mise à jour de votre fonction Lambda pour lire vos données de streaming Lambda fournit des informations sur les événements Kafka via le paramètre de méthode d’événement. Pour obtenir un exemple de structure d’un événement Amazon MSK, consultez [Exemple d’évènement](with-msk.md#msk-sample-event). Après avoir compris comment interpréter les événements Amazon MSK transférés par Lambda, vous pouvez modifier le code de votre fonction Lambda pour utiliser les informations qu’ils fournissent. Fournissez le code suivant à votre fonction Lambda pour journaliser le contenu d’un événement Lambda Amazon MSK à des fins de test : ------ #### [ .NET ] **SDK pour .NET** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant .NET. ``` using System.Text; using Amazon.Lambda.Core; using Amazon.Lambda.KafkaEvents; // Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class. [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace MSKLambda; public class Function { /// The event for the Lambda function handler to process. /// The ILambdaContext that provides methods for logging and describing the Lambda environment. /// public void FunctionHandler(KafkaEvent evnt, ILambdaContext context) { foreach (var record in evnt.Records) { Console.WriteLine("Key:" + record.Key); foreach (var eventRecord in record.Value) { var valueBytes = eventRecord.Value.ToArray(); var valueText = Encoding.UTF8.GetString(valueBytes); Console.WriteLine("Message:" + valueText); } } } } ``` ------ #### [ Go ] **Kit SDK pour Go V2** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant Go. ``` package main import ( "encoding/base64" "fmt" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" ) func handler(event events.KafkaEvent) { for key, records := range event.Records { fmt.Println("Key:", key) for _, record := range records { fmt.Println("Record:", record) decodedValue, _ := base64.StdEncoding.DecodeString(record.Value) message := string(decodedValue) fmt.Println("Message:", message) } } } func main() { lambda.Start(handler) } ``` ------ #### [ Java ] **SDK pour Java 2.x** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant Java. ``` import com.amazonaws.services.lambda.runtime.Context; import com.amazonaws.services.lambda.runtime.RequestHandler; import com.amazonaws.services.lambda.runtime.events.KafkaEvent; import com.amazonaws.services.lambda.runtime.events.KafkaEvent.KafkaEventRecord; import java.util.Base64; import java.util.Map; public class Example implements RequestHandler { @Override public Void handleRequest(KafkaEvent event, Context context) { for (Map.Entry> entry : event.getRecords().entrySet()) { String key = entry.getKey(); System.out.println("Key: " + key); for (KafkaEventRecord record : entry.getValue()) { System.out.println("Record: " + record); byte[] value = Base64.getDecoder().decode(record.getValue()); String message = new String(value); System.out.println("Message: " + message); } } return null; } } ``` ------ #### [ JavaScript ] **SDK pour JavaScript (v3)** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Utilisation d'un événement Amazon MSK avec JavaScript Lambda à l'aide de. ``` exports.handler = async (event) => { // Iterate through keys for (let key in event.records) { console.log('Key: ', key) // Iterate through records event.records[key].map((record) => { console.log('Record: ', record) // Decode base64 const msg = Buffer.from(record.value, 'base64').toString() console.log('Message:', msg) }) } } ``` Utilisation d'un événement Amazon MSK avec TypeScript Lambda à l'aide de. ``` import { MSKEvent, Context } from "aws-lambda"; import { Buffer } from "buffer"; import { Logger } from "@aws-lambda-powertools/logger"; const logger = new Logger({ logLevel: "INFO", serviceName: "msk-handler-sample", }); export const handler = async ( event: MSKEvent, context: Context ): Promise => { for (const [topic, topicRecords] of Object.entries(event.records)) { logger.info(`Processing key: ${topic}`); // Process each record in the partition for (const record of topicRecords) { try { // Decode the message value from base64 const decodedMessage = Buffer.from(record.value, 'base64').toString(); logger.info({ message: decodedMessage }); } catch (error) { logger.error('Error processing event', { error }); throw error; } }; } } ``` ------ #### [ PHP ] **Kit SDK pour PHP** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant PHP. ``` logger = $logger; } /** * @throws JsonException * @throws \Bref\Event\InvalidLambdaEvent */ public function handle(mixed $event, Context $context): void { $kafkaEvent = new KafkaEvent($event); $this->logger->info("Processing records"); $records = $kafkaEvent->getRecords(); foreach ($records as $record) { try { $key = $record->getKey(); $this->logger->info("Key: $key"); $values = $record->getValue(); $this->logger->info(json_encode($values)); foreach ($values as $value) { $this->logger->info("Value: $value"); } } catch (Exception $e) { $this->logger->error($e->getMessage()); } } $totalRecords = count($records); $this->logger->info("Successfully processed $totalRecords records"); } } $logger = new StderrLogger(); return new Handler($logger); ``` ------ #### [ Python ] **Kit SDK for Python (Boto3)** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant Python. ``` import base64 def lambda_handler(event, context): # Iterate through keys for key in event['records']: print('Key:', key) # Iterate through records for record in event['records'][key]: print('Record:', record) # Decode base64 msg = base64.b64decode(record['value']).decode('utf-8') print('Message:', msg) ``` ------ #### [ Ruby ] **Kit SDK pour Ruby** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant Ruby. ``` require 'base64' def lambda_handler(event:, context:) # Iterate through keys event['records'].each do |key, records| puts "Key: #{key}" # Iterate through records records.each do |record| puts "Record: #{record}" # Decode base64 msg = Base64.decode64(record['value']) puts "Message: #{msg}" end end end ``` ------ #### [ Rust ] **SDK pour Rust** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda). Consommation d’un événement Amazon MSK avec Lambda en utilisant Rust. ``` use aws_lambda_events::event::kafka::KafkaEvent; use lambda_runtime::{run, service_fn, tracing, Error, LambdaEvent}; use base64::prelude::*; use serde_json::{Value}; use tracing::{info}; /// Pre-Requisites: /// 1. Install Cargo Lambda - see https://www.cargo-lambda.info/guide/getting-started.html /// 2. Add packages tracing, tracing-subscriber, serde_json, base64 /// /// This is the main body for the function. /// Write your code inside it. /// There are some code example in the following URLs: /// - https://github.com/awslabs/aws-lambda-rust-runtime/tree/main/examples /// - https://github.com/aws-samples/serverless-rust-demo/ async fn function_handler(event: LambdaEvent) -> Result { let payload = event.payload.records; for (_name, records) in payload.iter() { for record in records { let record_text = record.value.as_ref().ok_or("Value is None")?; info!("Record: {}", &record_text); // perform Base64 decoding let record_bytes = BASE64_STANDARD.decode(record_text)?; let message = std::str::from_utf8(&record_bytes)?; info!("Message: {}", message); } } Ok(().into()) } #[tokio::main] async fn main() -> Result<(), Error> { // required to enable CloudWatch error logging by the runtime tracing::init_default_subscriber(); info!("Setup CW subscriber!"); run(service_fn(function_handler)).await } ``` ------ Vous pouvez fournir le code de fonction à votre fonction Lambda à l’aide de la console. **Pour mettre à jour le code de fonction à l’aide de l’éditeur de code de la console** 1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction. 1. Sélectionnez l’onglet **Code**. 1. Dans le volet **Source du code**, sélectionnez votre fichier de code source et modifiez-le dans l’éditeur de code intégré. 1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction : ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png) ## Test de votre fonction Lambda pour vérifier qu’elle est connectée à votre rubrique Amazon MSK Vous pouvez désormais vérifier si votre Lambda est invoqué par la source d'événements en consultant les journaux d'événements. CloudWatch **Pour vérifier si votre fonction Lambda est invoquée** 1. Utilisez votre hôte administrateur Kafka pour générer des événements Kafka à l’aide de la CLI `kafka-console-producer`. Pour plus d’informations, consultez [Write some events into the topic](https://kafka.apache.org/documentation/#quickstart_send) dans la documentation Kafka. Envoyez suffisamment d’événements pour remplir le lot défini en fonction de la taille du lot pour votre mappage des sources d’événements défini à l’étape précédente, sinon Lambda attendra d’autres informations pour procéder à l’invocation. 1. Si votre fonction s'exécute, Lambda écrit ce qui s'est passé à. CloudWatch Dans la console, accédez à la page des détails de votre fonction Lambda. 1. Sélectionnez l’onglet **Configuration**. 1. Dans la barre latérale, sélectionnez **Outils de surveillance et d’exploitation**. 1. Identifiez le **groupe de CloudWatch journaux** sous **Configuration de la journalisation**. Le groupe de journaux doit commencer par `/aws/lambda`. Choisissez le lien vers le groupe de journaux. 1. Dans la CloudWatch console, examinez les **événements du journal pour les événements** du journal que Lambda a envoyés au flux de journal. Identifiez s’il existe des événements de journaux contenant le message de votre événement Kafka, comme dans l’image suivante. Si tel est le cas, vous avez connecté avec succès une fonction Lambda à Amazon MSK à l’aide d’un mappage des sources d’événements Lambda. ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/msk_tut_log.png)