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.
Rôle d'exécution Lambda
Le rôle d'exécution d'une fonction Lambda est un rôle AWS Identity and Access Management (IAM) qui accorde à la fonction l'autorisation d'accéder aux services et aux ressources AWS. Par exemple, vous pouvez créer un rôle d'exécution autorisé à envoyer des journaux à Amazon CloudWatch et à y télécharger des données de suiviAWS X-Ray. Cette page fournit des informations sur la façon de créer, d'afficher et de gérer le rôle d'exécution d'une fonction Lambda.
Vous fournissez un rôle d'exécution lorsque vous créez une fonction. Lorsque vous appelez votre fonction, Lambda fournit automatiquement à celle-ci des informations d'identification temporaires en assumant ce rôle. Vous n'avez pas besoin d'appeler sts:AssumeRole dans votre code de fonction.
Pour que Lambda assume correctement votre rôle d'exécution, la politique de confiance du rôle doit spécifier le principal du service Lambda (lambda.amazonaws.com) comme un service de confiance.
Pour afficher le rôle d'exécution d'une fonction
Ouvrez la page Functions
(Fonctions) de la console Lambda. -
Choisissez le nom d’une fonction.
-
Choisissez Configuration (Configuration), puis Permissions (Autorisations).
-
Sous Récapitulatif des ressources, affichez les services et les ressources auxquels la fonction peut accéder.
-
Choisissez un service dans la liste déroulante pour afficher les autorisations associées à ce service.
À tout moment, vous pouvez ajouter ou supprimer des autorisations à partir du rôle d'exécution d'une fonction ou configurer votre fonction afin d'utiliser un autre rôle. Ajoutez des autorisations pour des services appelés par votre fonction avec le kit SDK AWS et pour des services utilisés par Lambda afin d'activer des fonctions facultatives.
Lorsque vous ajoutez des autorisations à votre fonction, mettez également à jour son code ou sa configuration. Vous forcez ainsi l'arrêt et le remplacement des instances en cours d'exécution de votre fonction qui ont des informations d'identification obsolètes.
Rubriques
- Création d'un rôle d'exécution dans la console IAM
- Accorder un accès assorti d'un privilège minimum à votre rôle d'exécution Lambda
- Gestion des rôles avec l'API IAM
- Durée de session pour les informations d'identification de sécurité provisoires
- Stratégies gérées par AWS pour les fonctions Lambda
- Utilisation des informations d'identification d'un environnement d'exécution Lambda
Création d'un rôle d'exécution dans la console IAM
Par défaut, Lambda crée un rôle d'exécution avec des autorisations minimales lorsque vous créez une fonction dans la console Lambda. Vous pouvez également créer un rôle d'exécution dans la console IAM.
Pour créer un rôle d'exécution dans la console IAM
-
Ouvrez la page Roles (Rôles)
dans la console IAM. -
Sélectionnez Créer un rôle.
-
Sous Cas d'utilisation, choisissez Lambda.
-
Choisissez Next (Suivant).
-
Sélectionnez les politiques AWS gérées AWSLambdaBasicExecutionRoleet AWSXRayDaemonWriteAccess.
-
Choisissez Suivant.
-
Entrez un nom dans Role name, puis choisissez Create role.
Pour obtenir les instructions complètes, consultez Création d'un rôle pour un service AWS (console) dans le Guide de l'utilisateur IAM.
Accorder un accès assorti d'un privilège minimum à votre rôle d'exécution Lambda
Lorsque vous créez pour la première fois un rôle IAM pour votre fonction Lambda pendant la phase de développement, il peut arriver que vous accordiez des autorisations au-delà de ce que est nécessaire. Avant de publier votre fonction dans l'environnement de production, une bonne pratique consiste à ajuster la stratégie de manière à inclure uniquement les autorisations requises. Pour en savoir plus, consultez Appliquer les autorisations de moindre privilège dans le Guide de l'utilisateur IAM.
Utilisez IAM Access Analyzer pour identifier les autorisations requises pour la stratégie de rôle d'exécution IAM. IAM Access Analyzer examine vos journaux AWS CloudTrail sur la plage de dates que vous spécifiez, et génère un modèle de stratégie avec uniquement les autorisations que la fonction a utilisées pendant cette période. Vous pouvez utiliser le modèle pour créer une stratégie gérée avec des autorisations affinées, puis l'attacher au rôle IAM. De cette façon, vous accordez uniquement les autorisations dont le rôle a besoin pour interagir avec les ressources AWS pour votre cas d’utilisation spécifique.
Pour en savoir plus, consultez Générer des stratégies basées sur l'activité d'accès dans le Guide de l'utilisateur IAM.
Gestion des rôles avec l'API IAM
Pour créer un rôle d'exécution avec l'AWS Command Line Interface(AWS CLI), utilisez la commande create-role. Lorsque vous utilisez cette commande, vous pouvez préciser la politique d'approbation en ligne. La politique d'approbation d'un rôle accorde aux principaux spécifiés l'autorisation d'assumer le rôle. Dans l'exemple suivant, vous accordez au service Lambda l'autorisation principale d'assumer votre rôle. Notez que les exigences relatives à l'échappement des guillemets dans la chaîne JSON peuvent varier en fonction de votre shell.
aws iam create-role --role-name lambda-ex --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
Vous pouvez également définir la politique d'approbation pour le rôle à l'aide d'un fichier JSON séparé. Dans l’exemple suivant, le fichier trust-policy.json se trouve dans le répertoire actuel.
Exemple trust-policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
aws iam create-role --role-name lambda-ex --assume-role-policy-document file://trust-policy.json
Vous devriez voir la sortie suivante :
{ "Role": { "Path": "/", "RoleName": "lambda-ex", "RoleId": "AROAQFOXMPL6TZ6ITKWND", "Arn": "arn:aws:iam::123456789012:role/lambda-ex", "CreateDate": "2020-01-17T23:19:12Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } }
Note
Lambda assume automatiquement votre rôle d'exécution lorsque vous appelez votre fonction. Vous devez éviter d'appeler sts:AssumeRole manuellement dans votre code de fonction. Si votre cas d'utilisation nécessite que le rôle soit assumé par lui-même, vous devez inclure le rôle lui-même en tant que principal approuvé dans la politique d'approbation de votre rôle. Pour en savoir plus sur la procédure de modification d'une politique d'approbation des rôles, consultez Modification d'une politique d'approbation de rôle (console)dans le Guide de l'utilisateur IAM.
Pour ajouter des autorisations au rôle, utilisez la commande attach-policy-to-role. Commencez par ajouter la stratégie gérée AWSLambdaBasicExecutionRole.
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Durée de session pour les informations d'identification de sécurité provisoires
Lambda endosse le rôle d'exécution associé à votre fonction pour récupérer les informations d'identification de sécurité provisoires qui sont ensuite fournies comme variables d'environnement lors de l'appel d'une fonction. Si vous utilisez ces informations d'identification temporaires en dehors de Lambda, par exemple pour créer une URL Amazon S3 présignée, vous ne pouvez pas contrôler la durée de la session. La configuration de la durée maximale de session IAM ne s'applique pas pour les sessions endossées par les services AWS tels que Lambda. Utilisez l'AssumeRoleaction sts : si vous avez besoin de contrôler la durée de la session.
Stratégies gérées par AWS pour les fonctions Lambda
Les stratégies gérées par AWS ci-après fournissent les autorisations requises pour utiliser les fonctions Lambda.
| Modification | Description | Date |
|---|---|---|
|
AWSLambdaMSKExecutionRole |
|
17 juin 2022 |
|
AWSLambdaBasicExecutionRole |
|
14 février 2022 |
|
AWSLambdaDynamoDBExecutionRole |
|
14 février 2022 |
|
AWSLambdaKinesisExecutionRole |
|
14 février 2022 |
|
AWSLambdaMSKExecutionRole |
|
14 février 2022 |
|
AWSLambdaSQSQueueExecutionRole |
|
14 février 2022 |
|
AWSLambdaVPCAccessExecutionRole |
|
14 février 2022 |
|
AWSXRayDaemonWriteAccess |
|
14 février 2022 |
|
CloudWatchLambdaInsightsExecutionRolePolicy |
|
14 février 2022 |
|
AmazonS3 — ObjectLambdaExecutionRolePolicy |
|
14 février 2022 |
Pour certaines fonctionnalités, la console Lambda tente d'ajouter les autorisations manquantes au rôle d'exécution dans une stratégie gérée par le client. Ces stratégies peuvent être excessivement nombreuses. Afin d'éviter la création de stratégies supplémentaires, ajoutez les stratégies gérées AWS pertinentes au rôle d'exécution avant d'activer les fonctions.
Lorsque vous utilisez un mappage de source d'événement pour appeler votre fonction, Lambda utilise le rôle d'exécution pour lire les données d'événement. Par exemple, un mappage de source d'événement pour Kinesis lit les événements d'un flux de données et les envoie à votre fonction par lots.
Lorsqu'un service endosse un rôle dans votre compte, vous pouvez inclure les clés de contexte de condition globale aws:SourceAccount et aws:SourceArn dans votre politique d'approbation des rôles afin de limiter l'accès au rôle aux seules demandes générées par les ressources attendues. Pour plus d'informations, consultez Prévention du problème de l'adjoint confus entre services pour AWS Security Token Service.
Vous pouvez utiliser les mappages de source d'événement avec les services suivants :
Services à partir desquels Lambda lit les événements
Outre les stratégies gérées par AWS, la console Lambda fournit des modèles permettant de créer une stratégie personnalisée dotée d'autorisations pour d'autres cas d'utilisation. Lorsque vous créez une fonction dans la console Lambda, vous pouvez choisir de créer un nouveau rôle d'exécution doté des autorisations d'un ou plusieurs modèles. Ces modèles s'appliquent également automatiquement lorsque vous créez une fonction à partir d'un plan ou lorsque vous configurez les options qui nécessitent l'accès à d'autres services. Des exemples de modèles sont disponibles dans le GitHubréférentiel
Utilisation des informations d'identification d'un environnement d'exécution Lambda
Il est courant que votre code de fonction Lambda envoie des requêtes API à d'autres AWS services. Pour effectuer ces requêtes, Lambda génère un ensemble éphémère d'informations d'identification en assumant le rôle d'exécution de votre fonction. Ces informations d'identification sont disponibles en tant que variables d'environnement lors de l'appel de votre fonction. Lorsque vous travaillez avec des kits SDK AWS, vous n'avez pas besoin de fournir des informations d'identification pour le kit SDK directement dans le code. Par défaut, la chaîne de fournisseurs d'informations d'identification vérifie séquentiellement chaque endroit où vous pouvez définir des informations d'identification et sélectionne le premier disponible, généralement les variables d'environnement (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_SESSION_TOKEN).
Lambda injecte l'ARN de la fonction source dans le contexte des informations d'identification si la demande est une demande d'API AWS provenant de votre environnement d'exécution. Lambda injecte également l'ARN de la fonction source pour les demandes d'API AWS suivantes que Lambda effectue en votre nom en dehors de votre environnement d'exécution :
| Service | Action | Raison |
|---|---|---|
| CloudWatch Journaux | CreateLogGroup, CreateLogStream, PutLogEvents |
Pour stocker les journaux dans un groupe de CloudWatch journaux |
| X-Ray | PutTraceSegments |
Pour envoyer des données de traçage à X-Ray |
| Amazon EFS | ClientMount |
Pour connecter votre fonction à un système de fichiers Amazon Elastic File System (Amazon EFS) |
Les autres appels d'API AWS que Lambda effectue en dehors de votre environnement d'exécution pour votre compte en utilisant le même rôle d'exécution ne contiennent pas l'ARN de la fonction source. Voici des exemples de tels appels d'API en dehors de l'environnement d'exécution :
-
Appels vers AWS Key Management Service (AWS KMS) pour chiffrer et déchiffrer automatiquement vos variables d'environnement.
-
Les appels à Amazon Elastic Compute Cloud (Amazon EC2) pour créer des interfaces réseau Elastic (ENI) pour une fonction compatible VPC.
-
Les appels aux services AWS, tels que Amazon Simple Queue Service (Amazon SQS), pour lire à partir d'une source d'événements configurée comme un mappage des sources d'événements.
Avec l'ARN de la fonction source dans le contexte des informations d'identification, vous pouvez vérifier si un appel à votre ressource provient du code d'une fonction Lambda spécifique. Pour vérifier cela, utilisez le clé de condition lambda:SourceFunctionArn dans une politique IAM basée sur l'identité ou politique de contrôle des services (SCP).
Note
Vous ne pouvez pas utiliser l'élément lambda:SourceFunctionArn dans les politiques basées sur les ressources.
À l'aide de cette clé de condition dans vos politiques basées sur l'identité ou SCP, vous pouvez implémenter des contrôles de sécurité pour les actions d'API que votre code de fonction fait à d'autres services AWS. Cela comporte quelques applications de sécurité clés, telles que l'identification de la source d'une fuite d'informations d'identification.
Note
La clé de condition lambda:SourceFunctionArn est différente des clés de condition lambda:FunctionArn et aws:SourceArn. Le clé de condition lambda:FunctionArn s'applique uniquement aux Mappages de sources d'événement et aide à définir les fonctions que votre source d'événement peut invoquer. La clé de condition aws:SourceArn s'applique uniquement aux politiques dans lesquelles votre fonction Lambda est la ressource cible et permet de définir quelles autres services et ressources AWS peuvent appeler cette fonction. Une clé de condition lambda:SourceFunctionArn peut s'appliquer à n'importe quelle politique basée sur l'identité ou SCP afin de définir les fonctions Lambda autorisées à effectuer des appels spécifiques d'API AWS vers d'autres ressources.
Pour utiliser lambda:SourceFunctionArn dans votre stratégie, incluez-la en tant que condition dans l'un des Opérateurs de condition ARN. La valeur de la clé doit être un ARN valide.
Par exemple, supposons que votre code de fonction Lambda émette un appel s3:PutObject qui cible un compartiment Amazon S3 spécifique. Vous pouvez vouloir n'autoriser qu'une fonction Lambda spécifique à avoir un accès s3:PutObject à ce compartiment. Dans ce cas, le rôle d'exécution de votre fonction doit être associé à une stratégie qui ressemble à ceci :
Exemple stratégie accordant à une fonction Lambda spécifique l'accès à une ressource Amazon S3
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ExampleSourceFunctionArn", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::lambda_bucket/*", "Condition": { "ArnEquals": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }
Cette politique permet uniquement un accès s3:PutObject si la source est la fonction Lambda avec ARN arn:aws:lambda:us-east-1:123456789012:function:source_lambda. Cette politique n'autorise pas un accès s3:PutObject à une autre identité d'appel. C'est le cas même si une fonction ou une entité différente émet un appel s3:PutObject avec le même rôle d'exécution.
Note
La clé de condition lambda:SourceFunctionARN ne prend pas en charge les versions des fonctions Lambda ni les alias de fonction. Si vous utilisez l'ARN pour une version ou un alias de fonction en particulier, votre fonction n'est pas autorisée à effectuer l'action que vous spécifiez. Veillez à utiliser l'ARN non qualifié pour votre fonction sans suffixe de version ou d'alias.
Vous pouvez également utiliser lambda:SourceFunctionArn dans des Politiques de contrôle des services. Supposons, par exemple, que vous souhaitiez limiter l'accès à votre compartiment à un code de fonction Lambda unique ou à des appels issus d'un cloud privé virtuel (VPC) Amazon. Le SCP suivant illustre ce processus.
Exemple politique refusant l'accès à Amazon S3 dans des conditions spécifiques
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:*" ], "Resource": "arn:aws:s3:::lambda_bucket/*", "Effect": "Deny", "Condition": { "StringNotEqualsIfExists": { "aws:SourceVpc": [ "vpc-12345678" ] }, "ArnNotEqualsIfExists": { "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda" } } } ] }
Cette stratégie refuse toutes les actions S3 sauf si elles proviennent d'une fonction Lambda spécifique avec ARN arn:aws:lambda:*:123456789012:function:source_lambda, ou à moins qu'ils ne proviennent du VPC spécifié. L’opérateur StringNotEqualsIfExists indique à IAM de traiter cette condition uniquement si la clé aws:SourceVpc est présente dans la demande. De la même façon, IAM considère l’opérateur ArnNotEqualsIfExists uniquement si le lambda:SourceFunctionArn existe.
