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. # Configuration des méthodes d’authentification de cluster dans Lambda Lambda prend en charge plusieurs méthodes d’authentification auprès de votre cluster Apache Kafka autogéré. Veillez à configurer le cluster Kafka pour utiliser l’une des méthodes d’authentification prises en charge suivantes : Pour de plus amples informations sur la sécurité, veuillez consulter la section [Sécurité](http://kafka.apache.org/documentation.html#security) de la documentation Kafka. ## SASL/SCRAM authentication Lambda prend en charge l'authentification et la sécurité simples Layer/Salted Mécanisme d'authentification des réponses aux défis (SASL/SCRAM) authentification avec 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 SASL/SCRAM authentification, voir [RÉFÉRENCE 5802](https://tools.ietf.org/html/rfc5802). Lambda prend également en charge SASL/PLAIN authentification. Comme ce mécanisme utilise des informations d’identification en texte clair, la connexion au serveur doit utiliser le chiffrement TLS pour garantir la protection des informations d’identification. Pour l’authentification SASL, vous devez stocker les informations d’identification en tant que secret dans AWS Secrets Manager. Pour plus d'informations sur l'utilisation de Secrets Manager, voir [Créez un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *AWS Secrets Manager Guide de l'utilisateur*. **Important** Pour utiliser Secrets Manager à des fins d'authentification, les secrets doivent être stockés dans le même AWS région comme fonction événementielle Lambda. ## Authentification TLS mutuelle Mutual TLS (mTLS) fournit une authentification bidirectionnelle entre le client et le serveur. Le client envoie un certificat au serveur pour que le serveur vérifie le client, et le serveur envoie un certificat au client pour que le client vérifie le serveur. Dans Apache Kafka autogéré, Lambda agit en tant que client. Vous configurez un certificat client (en tant que secret dans Secrets Manager) pour authentifier Lambda auprès des courtiers Kafka. Le certificat client doit être signé par une autorité de certification dans le magasin d’approbations du serveur. Le cluster Kafka envoie un certificat de serveur à Lambda pour authentifier les courtiers auprès de Lambda. Le certificat de serveur peut être un certificat CA public ou privé CA/self-signed certificat. Le certificat d’autorité de certification publique doit être signé par une autorité de certification située du magasin d’approbations Lambda. Pour un privé CA/self-signed certificat, vous configurez le certificat CA racine du serveur (en tant que secret dans Secrets Manager). Lambda utilise le certificat racine pour vérifier les courtiers Kafka. Pour de plus amples informations sur mTLS, veuillez consulter [Introduction d’une authentification TLS mutuelle pour Amazon MSK en tant que source d’événement](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source). ## Authentification OAuth 2.0 Supports Lambda SASL/OAUTHBEARER authentification avec chiffrement TLS (`SASL_SSL`). Lambda demande un jeton d'accès à votre fournisseur d'identité OAuth 2.0 et présente ce jeton à vos courtiers Kafka. Lambda actualise le jeton avant son expiration. Configurez vos courtiers pour qu'ils valident les jetons provenant du même fournisseur d'identité. Pour utiliser cette méthode, choisissez `OAUTHBEARER_AUTH` en tant que `Type` d'un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) et indiquez l'ARN du gestionnaire de secrets de votre secret OAuth dans le `URI` champ. Pour le contenu du secret, voir [Configuration du secret OAuth](#smaa-auth-oauth-secret). Lambda prend en charge deux types de subventions. Les champs que vous stockez dans le secret déterminent celui que Lambda utilise. + **Informations d'identification du client** — Lambda envoie un ID client et un code secret client au point de terminaison du jeton. Utilisez ce type d'autorisation lorsque votre fournisseur d'identité émet un secret client. + **porteur JWT** — Lambda signe une assertion JSON Web Token (JWT) avec une clé privée et envoie l'assertion au point de terminaison du jeton. Utilisez ce type d'autorisation lorsque votre fournisseur d'identité attend une assertion signée au lieu d'un secret client. Si votre fournisseur d'identité ou vos courtiers ont besoin de valeurs supplémentaires, indiquez chacune d'elles comme entrée de configuration d'accès à la source. Entrez la valeur littérale dans `URI` champ plutôt qu'un ARN secret. + `OAUTHBEARER_SCOPE` — L'étendue demandée par Lambda lorsqu'il demande un jeton. + `OAUTHBEARER_AUDIENCE` — L'audience que Lambda demande lorsqu'il demande un jeton. + `OAUTHBEARER_LOGICAL_CLUSTER` — L'ID de cluster logique que Lambda envoie à vos courtiers en tant qu'extension SASL. + `OAUTHBEARER_IDENTITY_POOL` — L'identifiant du pool d'identités que Lambda envoie à vos courtiers en tant qu'extension SASL. **Note** Ces quatre types nécessitent un type d'authentification OAuth 2.0. Fournissez-leur `OAUTHBEARER_AUTH`, ou fournissez uniquement `OAUTHBEARER_AUDIENCE` avec `IAM_OAUTHBEARER_AUTH`. Si vous fournissez l'un d'entre eux sans l'un de ces types d'authentification, Lambda renvoie une erreur de validation. Si vos courtiers présentent un certificat signé par une autorité de certification privée, fournissez également `SERVER_ROOT_CA_CERTIFICATE` afin que Lambda puisse les vérifier. Pour plus d’informations, consultez [Configuration du secret du certificat d’autorité de certification racine du serveur](#smaa-auth-ca-cert). ## Authentification IAM Si votre cluster est un cluster Amazon MSK auquel vous accédez via votre propre configuration réseau, vous pouvez l'enregistrer en tant que source d'événements Kafka autogérée et vous authentifier auprès d'IAM. Les configurations réseau personnalisées incluent un nom de domaine personnalisé devant vos courtiers ou une connexion depuis un autre compte. Lambda signe chaque connexion avec les informations d'identification du rôle d'exécution de votre fonction, de sorte que vous ne stockez aucune information d'identification dans Secrets Manager. Pour utiliser cette méthode, activez le contrôle d'accès IAM sur votre cluster. Ensuite, choisissez `IAM_AUTH` en tant que `Type` d'une configuration d'accès à la source et omettez le `URI` champ. Le rôle d'exécution de votre fonction nécessite les autorisations de cluster décrites dans [Configuration des autorisations de rôle d’exécution Lambda](with-kafka-permissions.md). Si vos courtiers présentent un certificat signé par une autorité de certification privée, fournissez également `SERVER_ROOT_CA_CERTIFICATE` afin que Lambda puisse les vérifier. Un nom de domaine personnalisé devant vos courtiers en a généralement besoin. ## Authentification IAM avec SASL/OAUTHBEARER Si vos courtiers acceptent les jetons OAuth 2.0, vous pouvez utiliser AWS en tant que fournisseur d'identité. Lambda présente un AWS jeton d'identité Web envoyé à vos courtiers SASL/OAUTHBEARER. Lambda demande un jeton de courte durée pour le rôle d'exécution de votre fonction avec `sts:GetWebIdentityToken` action, de sorte que vous ne stockez aucune information d'identification dans Secrets Manager. Lambda demande un nouveau jeton avant que le jeton actuel n'expire. Pour utiliser cette méthode, choisissez `IAM_OAUTHBEARER_AUTH` en tant que `Type` d'une configuration d'accès à la source et omettez le `URI` champ. Vous devez également fournir `OAUTHBEARER_AUDIENCE` auprès du public attendu par vos courtiers. Le rôle d'exécution de votre fonction nécessite une autorisation pour appeler `sts:GetWebIdentityToken`. Configurez vos courtiers pour qu'ils aient confiance AWS en tant que fournisseur d'identité OpenID Connect (OIDC) avant de créer le mappage des sources d'événements. Si vos courtiers ne font pas confiance à AWS émetteur, ils rejettent le jeton et Lambda ne peut pas lire les articles de vos sujets. **Note** `IAM_OAUTHBEARER_AUTH` supports uniquement `OAUTHBEARER_AUDIENCE`. Si vous fournissez également `OAUTHBEARER_SCOPE`, `OAUTHBEARER_LOGICAL_CLUSTER`, ou `OAUTHBEARER_IDENTITY_POOL`, Lambda renvoie une erreur de validation. ## 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. **Note** Lambda prend en charge les algorithmes de chiffrement de clés privées [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 \#8](https://datatracker.ietf.org/doc/html/rfc5208), avec la structure suivante : ``` -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ``` Pour une clé privée chiffrée, utilisez la structure suivante : ``` -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- ``` L’exemple suivant affiche le contenu d’un secret pour l’authentification mTLS à l’aide d’une clé privée chiffrée. Pour une clé privée chiffrée, incluez le mot de passe de clé privée dans le secret. ``` {"privateKeyPassword":"testpassword", "certificate":"-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey":"-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" } ``` ## Configuration du secret du certificat d’autorité de certification racine du serveur Vous créez ce secret si vos courtiers Kafka utilisent le chiffrement TLS avec des certificats signés par une autorité de certification privée. Vous pouvez utiliser le cryptage TLS pour VPC, SASL/SCRAM, SASL/PLAIN, ou authentification 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-----" } ``` ## Configuration du secret OAuth Vous créez ce secret lorsque vous utilisez `OAUTHBEARER_AUTH`. Le secret est un document JSON. Chaque secret OAuth a besoin `oauthTokenEndpointUrl` et `oauthClientId`. Ajoutez les champs pour un seul type de subvention. Si vous fournissez des champs provenant des deux types d'autorisation, Lambda renvoie une erreur de validation. | Champ | Obligatoire | Description | | --- | --- | --- | | `oauthTokenEndpointUrl` | O | Le point de terminaison du jeton de votre fournisseur d'identité. Il doit s’agir d’une URL HTTPS. | | `oauthClientId` | O | L'identifiant client que votre fournisseur d'identité a émis. | | `oauthClientSecret` | Informations d'identification du client uniquement | Le secret client émis par votre fournisseur d'identité. | | `oauthClientEmail` | Support JWT uniquement | L'identité du compte de service que Lambda met dans l'assertion JWT. | | `oauthPrivateKey` | Support JWT uniquement | La clé privée que Lambda utilise pour signer l'assertion JWT, au format PEM. | | `oauthTokenExpirationSeconds` | N | Durée de vie de l'assertion JWT signée par Lambda. S'applique uniquement au type de subvention JWT bearer. | | `oauthIdpCaCertificate` | N | Le certificat CA racine de votre fournisseur d'identité, au format PEM. Fournissez-le si votre fournisseur d'identité présente un certificat signé par une autorité de certification privée. | L'exemple suivant montre un secret pour le type d'autorisation des informations d'identification du client. ``` {"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token", "oauthClientId":"my-client-id", "oauthClientSecret":"my-client-secret"} ``` L'exemple suivant montre un secret pour le type de subvention JWT bearer. ``` {"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token", "oauthClientId":"my-client-id", "oauthClientEmail":"my-service-account@example.com", "oauthPrivateKey":"-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----"} ``` **Important** Stockez le secret dans le même AWS Région comme fonction Lambda. Lambda lit le secret avec le rôle d'exécution de votre fonction, de sorte que ce rôle a besoin `secretsmanager:GetSecretValue` autorisation sur le secret. Vous pouvez alterner les informations d'identification dans le secret sans recréer le mappage des sources d'événements. Lambda récupère les nouvelles valeurs et demande un nouveau jeton.