Comment résoudre les déclencheurs Lambda qui sondent depuis MSK et les clusters Kafka autogérés ?

Brève description

Un mappage des sources d'événements (ESM) est une ressource AWS Lambda qui lit à partir d'une source d'événements et invoque une fonction Lambda. Pour appeler une fonction Lambda, un ESM Lambda-Kafka doit être capable d'effectuer les actions suivantes :

• Communiquez avec le cluster.
• Résultats des sondages relatifs au sujet.
• Communiquez avec l'API Lambda Invoke.
• Communiquez avec l'API AWS Security Token Service (AWS STS).

Si les paramètres de mise en réseau, d'authentification ou d'autorisation d'un ESM empêchent la communication avec le cluster, la configuration échoue avant de pouvoir appeler une fonction. Le déclencheur affiche ensuite un message d'erreur qui permet de résoudre la cause première.

Résolution

Comprendre les ESM

Lorsqu'une fonction Lambda est configurée avec un déclencheur Amazon MSK ou un déclencheur Kafka autogéré, une ressource ESM est automatiquement créée. Un ESM est distinct de la fonction Lambda et interroge en permanence les interrogations du sujet dans le cluster Kafka. L'ESM regroupe ces enregistrements dans une charge utile. Il appelle ensuite l'API Lambda Invoke pour transmettre la charge utile à votre fonction Lambda à des fins de traitement.

Important : les ESM Lambda-Kafka n'héritent pas des paramètres réseau VPC de la fonction Lambda. Cela est vrai à la fois pour les déclencheurs MSK et les déclencheurs Kafka autogérés. Un MSK ESM utilise les paramètres de sous-réseau et de groupe de sécurité configurés sur le cluster MSK cible. Un déclencheur Kafka autogéré dispose d'un accès WAN par défaut, mais peut être configuré avec un accès réseau à un VPC appartenant au même compte et à la même région AWS. La configuration réseau étant séparée, une fonction Lambda peut exécuter du code au sein d'un réseau qui n'a pas de route vers le cluster Kafka.

Comprendre le processus de configuration de l'ESM

Avant que l'ESM puisse appeler la fonction Lambda associée, l'ESM effectue automatiquement les étapes suivantes :

1.    L'ESM appelle les API AWS STS pour obtenir un jeton de sécurité.

2.    Si SourceAccessConfiguration contient un secret, récupérez-le à partir de l'API AWS Secrets Manager.

3.    Pour Kakfa ESM autogéré : Lambda résout l'adresse IP des points de terminaison du cluster à partir du nom d'hôte configuré dans l'ESM, sous selfManagedEventSourceEndPoints.

      Pour MSK ESM : obtenez la configuration du sous-réseau et du groupe de sécurité du cluster MSK.

4.    Pour Kakfa ESM autogéré : établissez une connexion réseau avec le point de terminaison du courtier.

      Pour MSK ESM : créez une interface réseau Elastic hyperplan avec le groupe de sécurité du cluster MSK dans chacun des sous-réseaux du cluster MSK.

5.    Authentication :

• Si l'authentification TLS est activée, vérifiez le certificat SSL présenté par le point de terminaison du courtier.
• Connectez-vous au courtier.

6.    Autorisation :

• Assurez-vous que la rubrique existe dans le cluster. Demandez aux courtiers du cluster si le sujet configuré dans le paramètre Topics d'ESM existe dans le cluster.
• Créez un groupe de consommateurs dans le cluster en utilisant l'UUID de l'ESM comme identifiant de groupe de consommateurs.

7.    Résultats des sondages relatifs au sujet.

8.    Regroupez les enregistrements dans une charge utile inférieure à 6 Mo. C’est la limite pour les charges utiles d'invocation Lambda.

9.    L'ESM appelle la fonction Lambda associée avec la charge utile d'enregistrements. Pour ce faire, effectuez un appel synchrone à l'API Lambda Invoke.

Résolution des problèmes de sécurité du réseau

Lorsque l'ESM envoie une demande aux points de terminaison du courtier et ne reçoit aucune réponse, l'ESM considère que la demande a expiré. En cas d'expiration du délai d'accès au point de terminaison du courtier, le déclencheur affiche le message d'erreur suivant :

« PROBLÈME : erreur de connexion. Vérifiez la configuration de la connexion de votre source d'événements. Si la source de votre événement se trouve dans un VPC, essayez de configurer une nouvelle fonction Lambda ou une nouvelle instance EC2 avec les mêmes paramètres de VPC, de sous-réseau et de groupe de sécurité. Connectez le nouvel appareil au cluster Kafka et consommez des messages pour vous assurer que le problème n'est pas lié à la configuration du VPC ou du point de terminaison. Si le nouvel appareil est capable de recevoir des messages, veuillez contacter le service client de Lambda pour une enquête plus approfondie. »

Pour résoudre le problème, suivez les étapes indiquées dans le message d'erreur précédent. Notez également les configurations réseau décrites dans les sections suivantes pour vous assurer que votre ESM est correctement configuré.

Remarque : des demandes expirées émanant de l'ESM peuvent également survenir lorsque le cluster n'a plus de ressources système pour traiter la demande. Ou bien, des demandes expirées peuvent survenir lorsque des paramètres de sécurité incorrects sont configurés sur l'ESM ou le cluster. Si vous recevez cette erreur et que la configuration du réseau ne pose aucun problème, consultez les journaux d'accès du courtier de clusters pour obtenir des informations supplémentaires.

Configuration réseau utilisée par un Kafka ESM autogéré

La configuration réseau d'un Kafka ESM autogéré est similaire à une fonction Lambda. Par défaut, l'ESM a accès au WAN mais n'est pas configuré pour un accès au sein d'un VPC. Il peut être configuré manuellement avec des sous-réseaux et des groupes de sécurité spécifiques pour accéder à un cluster Kafka. Toutefois, il ne peut accéder à un cluster accessible depuis un VPC que dans le compte qui contient la fonction Lambda. Par conséquent, vous pouvez créer un Kafka ESM autogéré pour un cluster Kafka situé aux emplacements suivants :

• Centre de données sur site
• Autre fournisseur de cloud
• Les courtiers MSK d'un cluster Kafka situé dans le VPC d'un autre compte

Remarque : Il est possible de créer un déclencheur Kafka autogéré qui utilise les données d'un cluster MSK sur un autre compte. Cependant, il y a quelques inconvénients. Contrairement à un déclencheur MSK, l'authentification AWS Identity and Access Management (IAM) n'est pas disponible pour les déclencheurs Kafka autogérés. En outre, la connexion au cluster MSK via une connexion pair VPC nécessite des solutions de contournement spécifiques au VPC. Pour plus d'informations, consultez Comment Goldman Sachs crée une connectivité entre comptes vers ses clusters Amazon MSK avec AWS PrivateLink.

Configuration réseau d'un ESM Lambda-MSK

Pour communiquer avec le cluster MSK, un MSK ESM crée une interface réseau élastique hyperplane au sein de chaque sous-réseau utilisé par le cluster. Cela est similaire au fonctionnement d'une fonction Lambda au sein d'un VPC.

Un MSK ESM n'utilise pas les paramètres VPC de la fonction Lambda. Au lieu de cela, l'ESM utilise automatiquement les paramètres de sous-réseau et de groupe de sécurité configurés sur le cluster MSK cible. Le MSK ESM crée ensuite une interface réseau au sein de chacun des sous-réseaux utilisés par le cluster MSK. Ces interfaces réseau utilisent le même groupe de sécurité que celui utilisé par le cluster MSK. Les groupes de sécurité et les règles d'entrée ou de sortie utilisés par MSK ESM peuvent être trouvés à l'aide des commandes CLI suivantes :

1.    Utilisez la commande MSK describe-cluster de l'AWS CLI pour répertorier les groupes de sécurité et les sous-réseaux utilisés par le cluster MSK.

2.    Utilisez la commande describe-security-groups sur les groupes de sécurité répertoriés dans la sortie de describe-cluster.

Accorder l'accès au trafic

Le groupe de sécurité du cluster MSK doit inclure une règle qui accorde le trafic entrant en provenance de lui-même et le trafic sortant vers lui-même. Le trafic doit également être autorisé via l'un des ports d'authentification ouverts suivants utilisés par le courtier :

• 9092 pour le texte en clair
• 9094 pour TLS
• 9096 pour SASL
• 443 pour toutes les configurations

Résoudre les problèmes pouvant survenir lors de l'initialisation, de l'interrogation et de l'invocation

« PROBLÈME : erreur de connexion. Votre VPC doit pouvoir se connecter à Lambda et à STS, ainsi qu'à Secrets Manager si une authentification est requise. Vous pouvez fournir un accès en configurant PrivateLink ou une passerelle NAT. »

L'erreur précédente se produit pour les raisons suivantes :

• L'ESM est configuré dans un VPC et les appels à l'API STS échouent ou expirent.
• L'ESM est configuré dans un VPC et les tentatives de connexion à l'API Secrets Manager échouent ou expirent.
• Le déclencheur peut accéder à votre cluster Kafka, mais il expire lorsque vous appelez votre fonction via l'API Lambda.

Ces problèmes peuvent être dus à des paramètres VPC incorrects qui empêchent votre ESM d'accéder à d'autres services tels qu'AWS STS et AWS Secrets Manager. Suivez les étapes décrites dans Configuration d'AWS Lambda avec un cluster Apache Kafka au sein d'un VPC pour configurer correctement les paramètres de votre VPC.

Si les appels à l'API STS échouent ou expirent, les paramètres de votre VPC empêchent votre ESM d'atteindre le point de terminaison Lambda régional sur le port 443. Pour résoudre ce problème, consultez Configuration d'AWS Lambda avec un cluster Apache Kafka au sein d'un VPC.

Si SourceAccessConfiguration contient un secret, veillez à récupérer ce secret depuis Secrets Manager.

« PROBLÈME : Le certificat et/ou la clé privée doivent être au format PEM. »

L'erreur précédente se produit si vous avez un secret dont le format n'est pas déchiffrable par l'ESM.

Pour résoudre ce problème, vérifiez le format de votre secret. Notez que Secrets Manager ne prend en charge que les fichiers de certificat X.509 au format .pem. Pour plus d'informations, voir le certificat fourni ou la clé privée n'est pas valide (Amazon MSK) ou le certificat ou la clé privée fournis ne sont pas valides (Kafka).

« PROBLÈME : Les points de terminaison fournis par Kafka Broker ne peuvent pas être résolus. »

L'erreur précédente se produit lorsque votre ESM ne parvient pas à traduire le nom d'hôte en adresse IP.

Pour résoudre cette erreur, assurez-vous que l'ESM est en mesure d'atteindre un serveur DNS capable de traduire le nom d'hôte. Si le nom d'hôte du point de terminaison se trouve dans un réseau privé, configurez l'ESM pour utiliser un VPC avec des paramètres DNS capables de résoudre le nom d'hôte.

« PROBLÈME : Le serveur n'a pas réussi à authentifier Lambda ou Lambda n'a pas réussi à authentifier le serveur. »

L'erreur précédente se produit lorsque le serveur auquel votre ESM est connecté n'est pas le serveur que vous avez configuré dans les paramètres ESM.

Pour résoudre ce problème, vérifiez que vous avez configuré les paramètres de votre ESM pour le serveur auquel vous vous connectez.

« PROBLÈME : échec de l'authentification SASL. »

L'erreur précédente se produit lorsque votre tentative de connexion au serveur échoue.

Les fonctions AWS Lambda déclenchées à partir d'une rubrique Amazon MSK peuvent accéder à des noms d'utilisateur et à des mots de passe sécurisés par AWS Secrets Manager à l'aide de SASL/SCRAM. Un message d'erreur s'affiche lorsque votre nom d'utilisateur et votre mot de passe ne sont pas reconnus comme valides.

Pour résoudre cette erreur, connectez-vous au courtier et consultez les journaux d'accès.

Remarque :

« PROBLÈME : le cluster n'a pas réussi à autoriser Lambda. »

L'erreur précédente se produit lorsque l'ESM se connecte au courtier, mais que l'utilisateur de l'ESM n'est pas autorisé à interroger les enregistrements de la rubrique. Pour résoudre ce problème, consultez Cluster n'a pas réussi à autoriser Lambda (Amazon MSK) ou Cluster n'a pas réussi à autoriser Lambda (Kafka).

---

Informations connexes

Erreurs d’authentication et d’autorisation