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é
SASL/SCRAM authentication
Lambda prend en charge l'authentification simple et l'authentification par mécanisme d'authentification par réponse aux Layer/Salted défis de sécurité (SASL/SCRAM) avec le cryptage TLS (Transport Layer Security) (). SASL_SSL Lambda envoie les informations d’identification chiffrées pour s’authentifier auprès du cluster. Lambda n'est pas compatible SASL/SCRAM avec plaintext (). SASL_PLAINTEXT Pour plus d'informations sur SASL/SCRAM l'authentification, consultez la RFC 5802
Lambda prend également en charge SASL/PLAIN l'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, consultez la section Créer un AWS Secrets Manager secret dans le Guide de AWS Secrets Manager l'utilisateur.
Important
Pour utiliser Secrets Manager pour l'authentification, les secrets doivent être stockés dans la même AWS région que votre fonction d'événement 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 . Le certificat d’autorité de certification publique doit être signé par une autorité de certification située du magasin d’approbations Lambda. Pour un CA/self-signed certificat privé, 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
Authentification OAuth 2.0
Lambda prend en charge SASL/OAUTHBEARER l'authentification avec le cryptage 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 la OAUTHBEARER_AUTH valeur Type de a SourceAccessConfigurationet indiquez l'ARN du Gestionnaire de Secrets de votre secret OAuth dans le URI champ. Pour le contenu du secret, voirConfiguration du secret OAuth.
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 secret client au point de terminaison du jeton. Utilisez ce type d'autorisation lorsque votre fournisseur d'identité émet un secret client.
-
Support 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 le URI champ plutôt qu'un ARN secret.
-
OAUTHBEARER_SCOPE— La portée demandée par Lambda lorsqu'elle demande un jeton. -
OAUTHBEARER_AUDIENCE— L'audience que Lambda demande lorsqu'elle demande un jeton. -
OAUTHBEARER_LOGICAL_CLUSTER— L'ID de cluster logique que Lambda envoie à vos courtiers sous forme d'extension SASL. -
OAUTHBEARER_IDENTITY_POOL— L'ID du pool d'identités que Lambda envoie à vos courtiers sous forme d'extension SASL.
Note
Ces quatre types nécessitent un type d'authentification OAuth 2.0. Fournissez-leurOAUTHBEARER_AUTH, ou OAUTHBEARER_AUDIENCE fournissez-les uniquementIAM_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-le également SERVER_ROOT_CA_CERTIFICATE afin que Lambda puisse le vérifier. Pour plus d’informations, consultez Configuration du secret du certificat d’autorité de certification racine du serveur.
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. Choisissez ensuite IAM_AUTH comme configuration Type 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 dansConfiguration des autorisations de rôle d’exécution Lambda.
Si vos courtiers présentent un certificat signé par une autorité de certification privée, fournissez-le également SERVER_ROOT_CA_CERTIFICATE afin que Lambda puisse le 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 les utiliser AWS comme fournisseur d'identité. Lambda présente un jeton d'identité AWS Web à vos courtiers. SASL/OAUTHBEARER Lambda demande un jeton de courte durée pour le rôle d'exécution de votre fonction dans l'sts:GetWebIdentityTokenaction, de sorte que vous ne stockez aucune information d'identification dans Secrets Manager. Lambda demande un nouveau jeton avant l'expiration du jeton actuel.
Pour utiliser cette méthode, choisissez IAM_OAUTHBEARER_AUTH comme configuration Type d'accès à la source et omettez le URI champ. Vous devez également OAUTHBEARER_AUDIENCE fournir le public auquel vos courtiers s'attendent. Le rôle d'exécution de votre fonction doit être autorisé pour appelersts:GetWebIdentityToken.
Configurez vos courtiers de manière à ce qu'ils aient confiance en AWS 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 à l' AWS émetteur, ils rejettent le jeton et Lambda ne peut pas lire vos sujets.
Note
IAM_OAUTHBEARER_AUTHsupports uniquementOAUTHBEARER_AUDIENCE. Si vous fournissez égalementOAUTHBEARER_SCOPE, ou OAUTHBEARER_LOGICAL_CLUSTEROAUTHBEARER_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
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
-----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 SASL/SCRAM, SASL/PLAIN, ou 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 utilisezOAUTHBEARER_AUTH. Le secret est un document JSON. Chaque secret OAuth a besoin oauthTokenEndpointUrl de et. oauthClientId Ajoutez les champs pour un seul type de subvention. Si vous fournissez des champs provenant des deux types de subvention, Lambda renvoie une erreur de validation.
| Champ | Obligatoire | Description |
|---|---|---|
|
O |
Le point de terminaison du jeton de votre fournisseur d'identité. Il doit s’agir d’une URL HTTPS. |
|
O |
L'ID client émis par votre fournisseur d'identité. |
|
Informations d'identification du client uniquement |
Le secret client émis par votre fournisseur d'identité. |
|
Support JWT uniquement |
L'identité du compte de service que Lambda met dans l'assertion JWT. |
|
Support JWT uniquement |
La clé privée que Lambda utilise pour signer l'assertion JWT, au format PEM. |
|
N |
Durée de vie de l'assertion JWT signée par Lambda. S'applique uniquement au type de subvention JWT bearer. |
|
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-----
<private key contents>
-----END PRIVATE KEY-----"}
Important
Stockez le secret dans la même AWS région que votre fonction Lambda. Lambda lit le secret avec le rôle d'exécution de votre fonction, de sorte que ce rôle a besoin d'une secretsmanager:GetSecretValue autorisation sur le secret.
Vous pouvez faire pivoter 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.
