Configuration de sources d’événements Apache Kafka autogérées pour Lambda

Avant de créer un mappage des sources d’événements pour votre cluster Apache Kafka autogéré, 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 Apache Kafka autogéré, votre VPC et votre fonction Lambda. Pour savoir comment créer le mappage des sources d’évènements, consultez Ajout d’un cluster Kafka en tant que source d’événement.

Authentification de cluster Kafka

Lambda prend en charge plusieurs méthodes d’authentification auprès de votre cluster Apache Kafka autogéré. Veillez à configurer le cluster Kafka pour utiliser l’une des méthodes d’authentification prises en charge suivantes : Pour de plus amples informations sur la sécurité, veuillez consulter la section Sécurité de la documentation Kafka.

Authentification SASL/SCRAM

Lambda prend en charge l'authentification (Simple Authentication and SecurityLayer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) avec le chiffrement TLS (Transport Layer Security) (). SASL_SSL Lambda envoie les informations d’identification chiffrées pour s’authentifier auprès du cluster. Lambda ne prend pas en charge SASL/SCRAM avec du texte en clair (SASL_PLAINTEXT). Pour plus d’informations sur l’authentification SASL/SCRAM, consultez RFC 5802.

Lambda prend également en charge l’authentification SASL/PLAIN. Comme ce mécanisme utilise des informations d’identification en texte clair, la connexion au serveur doit utiliser le chiffrement TLS pour garantir la protection des informations d’identification.

Pour l’authentification SASL, vous devez stocker les informations d’identification en tant que secret dans AWS Secrets Manager. Pour plus d’informations sur l’utilisation de Secrets Manager, consultez Didacticiel : création et récupération d’un secret dans le Guide de l’utilisateur AWS Secrets Manager .

Authentification TLS mutuelle

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

Dans Apache Kafka autogéré, Lambda agit en tant que client. Vous configurez un certificat client (en tant que secret dans Secrets Manager) pour authentifier Lambda auprès des courtiers Kafka. Le certificat client doit être signé par une autorité de certification dans le magasin d’approbations du serveur.

Le cluster Kafka envoie un certificat de serveur à Lambda pour authentifier les courtiers auprès de Lambda. Le certificat de serveur peut être un certificat d'autorité de certification public ou privéCA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self, vous configurez le certificat d'autorité de certification racine du serveur (en tant que secret dans Secrets Manager). Lambda utilise le certificat racine pour vérifier les courtiers Kafka.

Pour de plus amples informations sur mTLS, veuillez consulter Introduction d’une authentification TLS mutuelle pour Amazon MSK en tant que source d’événement.

Configuration du secret du certificat client

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, incluez le mot de passe de clé privée dans le secret.

{"privateKeyPassword":"testpassword",
"certificate":"-----BEGIN CERTIFICATE-----
MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw
...
j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk
cmUuiAii9R0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb
...
rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no
c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg==
-----END CERTIFICATE-----",
"privateKey":"-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp
...
QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ
zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA==
-----END ENCRYPTED PRIVATE KEY-----"
}

Configuration du secret du certificat d’autorité de certification racine du serveur

Vous créez ce secret si vos courtiers Kafka utilisent le chiffrement TLS avec des certificats signés par une autorité de certification privée. Vous pouvez utiliser le chiffrement TLS pour l'authentification VPC ou SASL/SCRAM, SASL/PLAIN mTLS.

Le secret du certificat d’autorité de certification racine du serveur nécessite un champ contenant le certificat d’autorité de certification racine du courtier Kafka au format PEM. La structure du secret est présentée dans l’exemple suivant.

{"certificate":"-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs
ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG...
-----END CERTIFICATE-----"
}

Accès à l’API et autorisations de fonction Lambda

En plus d’accéder au cluster Amazon Kafka autogéré, votre fonction Lambda a besoin d’autorisations pour effectuer diverses actions d’API. Ajoutez ces autorisations au rôle d’exécution de votre fonction. Si vos utilisateurs ont besoin d'accéder à des actions d'API, ajoutez les autorisations requises à la politique d'identité de l'utilisateur ou du rôle AWS Identity and Access Management (IAM).

Autorisations de fonction Lambda requises

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

Autorisations de fonction Lambda facultatives

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

Secrets Manager et AWS KMS autorisations

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

Autorisations VPC

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

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

Pour accéder à d'autres Services AWS sites utilisés par votre cluster Apache Kafka autogéré, Lambda utilise les politiques d'autorisation que vous définissez dans le rôle d'exécution de votre fonction Lambda.

Par défaut, Lambda n’est pas autorisé à exécuter les actions obligatoires ou facultatives pour un cluster Apache Kafka autogéré. Vous devez créer et définir ces actions dans une stratégie d’approbation IAM pour votre rôle d’exécution. Cet exemple montre comment créer une stratégie autorisant Lambda à accéder à vos ressources Amazon VPC.

{
        "Version":"2012-10-17",
        "Statement":[
           {
              "Effect":"Allow",
              "Action":[
                 "ec2:CreateNetworkInterface",
                 "ec2:DescribeNetworkInterfaces",
                 "ec2:DescribeVpcs",
                 "ec2:DeleteNetworkInterface",
                 "ec2:DescribeSubnets",
                 "ec2:DescribeSecurityGroups"
              ],
              "Resource":"*"
           }
        ]
     }

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

Par défaut, les utilisateurs et les rôles n’ont pas l’autorisation d’effectuer des opérations d’API de source d’événement. Pour accorder l’accès aux utilisateurs de votre organisation ou de votre compte, vous pouvez ajouter ou mettre à jour une stratégie basée sur l’identité. Pour plus d'informations, consultez la section Contrôle de l'accès aux AWS ressources à l'aide de politiques dans le Guide de l'utilisateur IAM.

Configurer la sécurité réseau

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

Lorsque vous utilisez Apache Kafka autogéré avec Lambda, créez des points de terminaison de VPC AWS PrivateLink 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 Apache Kafka autogéré, Lambda vérifie si des interfaces réseau élastiques (ENIs) sont déjà présentes pour les sous-réseaux et les groupes de sécurité 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, Apache Kafka autogéré utilise les ports suivants : 9092.

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": "*"
          }
      ]
  }