Configuration de source d’événements Amazon MSK pour Lambda

Avant de créer un mappage des sources d’événements pour votre cluster Amazon MSK, vous devez vous assurer que votre cluster et le VPC dans lequel il réside sont correctement configurés. Vous devez également vous assurer que le rôle d’exécution de votre fonction Lambda dispose des autorisations IAM nécessaires.

Suivez les instructions des sections suivantes pour configurer votre cluster Amazon MSK, votre VPC et votre fonction Lambda. Pour savoir comment créer le mappage des sources d’évènements, consultez Ajout d’Amazon MSK en tant que source d’événement.

Authentification du cluster MSK

Lambda doit être autorisé à accéder au cluster Amazon MSK, à récupérer des enregistrements et à effectuer d’autres tâches. Amazon MSK prend en charge plusieurs options de contrôle de l’accès client au cluster MSK.

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

Amazon MSK prend en charge l'authentification simple (authentification et sécuritéLayer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) avec le chiffrement TLS (Transport Layer Security). Pour que Lambda puisse se connecter au cluster, vous devez stocker les informations d'authentification (nom d'utilisateur et mot de passe) dans un AWS Secrets Manager secret.

Pour plus d’informations sur l’utilisation de Secrets Manager, consultez Authentification par nom d’utilisateur et mot de passe avec AWS Secrets Manager dans le Guide du développeur Amazon Managed Streaming for Apache Kafka.

Notez qu’Amazon MSK ne prend pas en charge l’authentification SASL/PLAIN.

Authentification basée sur les rôles IAM

Vous pouvez utiliser IAM pour authentifier l’identité des clients qui se connectent au cluster MSK. Si l’authentification IAM est active sur votre cluster MSK et que vous ne fournissez pas de secret pour l’authentification, Lambda utilise automatiquement l’authentification IAM par défaut. Pour créer et déployer des politiques basées sur les utilisateurs ou les rôles, utilisez la console IAM ou l’API. Pour plus d’informations, consultez Contrôle d’accès IAM dans le Guide du développeur Amazon Managed Streaming for Apache Kafka.

Pour permettre à Lambda de se connecter au cluster MSK, de lire des enregistrements et d’effectuer d’autres actions requises, ajoutez les autorisations suivantes à votre rôle d’exécution de fonction.

{
    "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:region:account-id:cluster/cluster-name/cluster-uuid",
                "arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name",
                "arn:aws:kafka:region:account-id:group/cluster-name/cluster-uuid/consumer-group-id"
            ]
        }
    ]
}       

Vous pouvez étendre ces autorisations à un cluster, une rubrique et un groupe spécifiques. Pour plus d’informations, consultez Actions Amazon MSK Kafka dans le Guide du développeur Amazon Managed Streaming for Apache Kafka.

Authentification TLS mutuelle

Mutual TLS (mTLS) fournit une authentification bidirectionnelle entre le client et le serveur. Le client envoie un certificat au serveur pour que le serveur vérifie le client, et le serveur envoie un certificat au client pour que le client vérifie le serveur.

Pour Amazon MSK, Lambda agit en tant que client. Vous configurez un certificat client (en tant que secret dans Secrets Manager) pour authentifier Lambda auprès des courtiers de votre cluster MSK. Le certificat client doit être signé par une autorité de certification dans le magasin d’approbations du serveur. Le cluster MSK envoie un certificat de serveur à Lambda pour authentifier les courtiers auprès de Lambda. Le certificat du serveur doit être signé par une autorité de certification (CA) présente dans le AWS trust store.

Pour obtenir des instructions sur la façon de générer un certificat client, consultez Présentation de l’authentification TLS mutuelle pour Amazon MSK en tant que source d’événement.

Amazon MSK ne prend pas en charge les certificats de serveur auto-signés, car tous les courtiers d'Amazon MSK utilisent des certificats publics signés par Amazon Trust Services, CAs auxquels Lambda fait confiance par défaut.

Pour plus d’informations sur le protocole mTLS pour Amazon MSK, consultez Authentification Mutual TLS dans le Guide du développeur Amazon Managed Streaming for Apache Kafka.

Configuration du secret mTLS

Le secret CLIENT_CERTIFICATE_TLS_AUTH 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.

Le champ de certificat doit contenir une liste de certificats, commençant par le certificat client, suivi de tous les certificats intermédiaires et se terminant par le certificat racine. Chaque certificat doit commencer sur une nouvelle ligne avec la structure suivante :

-----BEGIN CERTIFICATE-----  
        <certificate contents>
-----END CERTIFICATE-----      

Secrets Manager prend en charge les secrets jusqu’à 65 536 octets, ce qui offre suffisamment d’espace pour de longues chaînes de certificats.

La clé privée doit être au format PKCS #8, avec la structure suivante :

-----BEGIN PRIVATE KEY-----  
         <private key contents>
-----END PRIVATE KEY-----            

Pour une clé privée chiffrée, utilisez la structure suivante :

-----BEGIN ENCRYPTED PRIVATE KEY-----  
          <private key contents>
-----END ENCRYPTED PRIVATE KEY-----           

L’exemple suivant 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-----"
} 

Comment Lambda choisit un courtier bootstrap

Lambda choisit un courtier d’amorçage 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 :

Gestion des accès et des autorisations d’API

En plus d’accéder au cluster Amazon MSK, votre fonction a besoin d’autorisations pour effectuer diverses actions de l’API Amazon MSK. Ajoutez les autorisations d’écriture au rôle d’exécution de votre fonction. Si vos utilisateurs ont besoin d’accéder à l’une des actions de l’API Amazon MSK, ajoutez les autorisations requises à la politique d’identité de l’utilisateur ou du rôle correspondant.

Vous pouvez ajouter manuellement chacune des autorisations suivantes à votre rôle d’exécution. Vous pouvez également associer le AWSLambdaMSKExecutionrôle de politique AWS géré à votre rôle d'exécution. La politique AWSLambdaMSKExecutionRole contient toutes les actions d’API requises et les autorisations VPC répertoriées ci-dessous.

Autorisations de rôle d’exécution de fonction Lambda requises

Pour créer et stocker des journaux dans un groupe de CloudWatch journaux dans Amazon Logs, votre fonction Lambda doit disposer des autorisations suivantes dans son rôle d'exécution :

Pour que Lambda puisse accéder à votre cluster Amazon MSK en votre nom, votre fonction Lambda doit disposer des autorisations suivantes dans son rôle d’exécution :

Vous n’avez besoin d’ajouter que kafka:DescribeCluster ou kafka:DescribeClusterV2. Pour les clusters MSK alloués, l’une ou l’autre des autorisations fonctionne. Pour les clusters MSK sans serveur, vous devez utiliser kafka:DescribeClusterV2.

Autorisations VPC

Si seuls des utilisateurs au sein d’un VPC peuvent accéder à votre cluster Amazon MSK, votre fonction Lambda doit être autorisée à accéder à vos ressources Amazon VPC. Ces ressources incluent les sous-réseaux, groupes de sécurité et interfaces réseau de votre VPC. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes. Ces autorisations sont incluses dans la politique de AWS gestion des AWSLambdaMSKExecutionrôles.

Autorisations de fonction Lambda facultatives

Votre fonction Lambda peut également nécessiter ces autorisations pour :

Secrets Manager et AWS KMS autorisations

Selon le type de contrôle d'accès que vous configurez pour vos courtiers Amazon MSK, votre fonction Lambda peut avoir besoin d'une autorisation pour accéder à votre secret SCRAM (si vous utilisez l'authentification SASL/SCRAM) ou au secret Secrets Manager pour déchiffrer votre clé gérée par le client. AWS KMS Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes :

Ajout d’autorisations à votre rôle d’exécution

Suivez ces étapes pour ajouter le rôle de stratégie AWS géré à votre AWSLambdaMSKExecutionrôle d'exécution à l'aide de la console IAM.

Octroi d’accès à des utilisateurs avec une politique IAM

Par défaut, les utilisateurs et les rôles ne sont pas autorisés à effectuer des opérations d’API Amazon MSK. Pour accorder l’accès aux utilisateurs de votre organisation ou de votre compte, vous pouvez ajouter ou mettre à jour une politique basée sur l’identité. Pour plus d’informations, consultez Exemples de politiques basées sur une identité Amazon MSK dans le Guide du développeur Amazon Managed Streaming for Apache Kafka.

Authentification et erreurs d’autorisation

Si l'une des autorisations requises pour utiliser les données du cluster Amazon MSK est manquante, Lambda affiche l'un des messages d'erreur suivants dans le mappage des sources d'événements ci-dessous. LastProcessingResult

Le cluster n’a pas pu autoriser Lambda

Pour SASL/SCRAM ou mTLS, cette erreur indique que l’utilisateur fourni ne dispose pas de toutes les autorisations de liste de contrôle d’accès (ACL) Kafka requises suivantes :

Pour le contrôle d’accès IAM, le rôle d’exécution de fonction ne dispose pas d’une ou de plusieurs autorisations requises pour accéder au groupe ou à la rubrique. Passez en revue la liste des autorisations requises dans Authentification basée sur les rôles IAM.

Lorsque vous créez une politique Kafka ACLs ou IAM avec les autorisations de cluster Kafka requises, spécifiez le sujet et le groupe en tant que ressources. Le nom de la rubrique doit correspondre à la rubrique dans le mappage des sources d’événements. Le nom du groupe doit correspondre à l’UUID du mappage des sources d’événements.

Une fois que vous avez ajouté les autorisations requises au rôle d’exécution, il peut y avoir un délai de plusieurs minutes avant que les modifications ne prennent effet.

Échec de l’authentification SASL

Pour SASL/SCRAM, cet échec indique que le nom d’utilisateur et le mot de passe fournis ne sont pas valides.

Pour le contrôle d’accès IAM, le rôle d’exécution est manquant kafka-cluster:Connect autorisations pour le cluster. Ajoutez cette autorisation au rôle et spécifiez l’Amazon Resource Name (ARN) du cluster en tant que ressource.

Cette erreur peut se produire de façon intermittente. Le cluster rejette les connexions une fois que le nombre de connexions TCP dépasse le Quota de service Amazon MSK. Lambda fait marche arrière et tente de nouveau jusqu’à ce qu’une connexion soit réussie. Une fois que Lambda se connecte au cluster et interroge les enregistrements, le dernier résultat de traitement passe à OK.

Le serveur n’a pas réussi à authentifier Lambda

Cette erreur indique que les courtiers Amazon MSK Kafka n’ont pas réussi à s’authentifier auprès de Lambda. Cette erreur se produit dans les conditions suivantes :

Le certificat ou la clé privée fournis n’est pas valide

Cette erreur indique que le consommateur Amazon MSK n’a pas pu utiliser le certificat ou la clé privée fournis. Assurez-vous que le certificat et la clé utilisent le format PEM et que le chiffrement par clé privée utilise un PBES1 algorithme.

Configurer la sécurité réseau

Pour donner à Lambda un accès complet à Amazon MSK via votre mappage des sources d’événements, soit votre cluster doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé le cluster.

Lorsque vous utilisez Amazon MSK avec Lambda, créez des points de terminaison de VPC AWS PrivateLink qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC.

Créez un point de terminaison pour accéder aux ressources suivantes :

Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, veuillez consulter Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC.

Lorsque vous créez un mappage de source d'événements pour Amazon MSK, Lambda vérifie si des interfaces réseau élastiques ENIs () sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre Amazon VPC. Si Lambda trouve des objets existants ENIs, il essaie de les réutiliser. Sinon, Lambda en crée un nouveau ENIs pour se connecter à la source de l'événement et appeler votre fonction.

Configurez les groupes de sécurité pour le VPC Amazon contenant votre cluster. Par défaut, Amazon MSK utilise les ports suivants : 9092 pour le texte brut, 9094 pour TLS, 9096 pour SASL, 9098 pour IAM.

Si votre cluster utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda.

{
      "Statement": [
          {
              "Action": "secretsmanager:GetSecretValue",
              "Effect": "Allow",
              "Principal": {
                  "AWS": [
                      "arn:aws::iam::123456789012:role/my-role"
                  ]
              },
              "Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
          }
      ]
  }

Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d'API pour appeler votre fonction à l'aide de l'Elastic Network Interface (ENI) du point de terminaison. Le directeur du service Lambda doit faire appel à tous lambda:InvokeFunction les rôles et fonctions qui les utilisent. ENIs

Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler sts:AssumeRole et lambda:InvokeFunction. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi "Resource": "*" est requis dans ces politiques.

Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda.

{
      "Statement": [
          {
              "Action": "sts:AssumeRole",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
    }

{
      "Statement": [
          {
              "Action": "lambda:InvokeFunction",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
  }