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. # Politiques IAM basées sur l’identité pour Lambda Vous pouvez utiliser des politiques basées sur l'identité dans Gestion des identités et des accès AWS (IAM) pour autoriser les utilisateurs de votre compte à accéder à Lambda. Les politiques basées sur l’identité peuvent s’appliquer aux utilisateurs, aux groupes d’utilisateurs ou aux rôles. Vous pouvez également accorder aux utilisateurs d’un autre compte l’autorisation d’endosser un rôle de votre compte et d’accéder à vos ressources Lambda. Lambda fournit des politiques AWS gérées qui accordent l'accès aux actions de l'API Lambda et, dans certains cas, à d'autres AWS services utilisés pour développer et gérer les ressources Lambda. Lambda met à jour ces stratégies gérées si nécessaire pour s’assurer que vos utilisateurs ont accès aux nouvelles fonctionnalités quand elles sont disponibles. + [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Accorde un accès complet aux actions Lambda et aux autres AWS services utilisés pour développer et gérer les ressources Lambda. + [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Accorde un accès en lecture seule aux ressources Lambda. + [AWSLambdaRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) : accorde des autorisations pour appeler des fonctions Lambda. AWS les politiques gérées autorisent les actions d'API sans restreindre les fonctions ou les couches Lambda qu'un utilisateur peut modifier. Pour bénéficier d’un contrôle plus précis, vous pouvez créer vos propres stratégies qui limitent la portée des autorisations d’un utilisateur. **Topics** + [Octroi aux utilisateurs de l’accès à une fonction Lambda](permissions-user-function.md) + [Octroi aux utilisateurs de l’accès à une couche Lambda](permissions-user-layer.md) # Octroi aux utilisateurs de l’accès à une fonction Lambda Utilisez des [politiques basées sur l’identité](access-control-identity-based.md) pour autoriser des utilisateurs, des groupes d’utilisateurs ou des groupes à effectuer des opérations sur des fonctions Lambda. **Note** Pour une fonction définie comme une image de conteneur, l’autorisation des utilisateurs à accéder à l’image doit être configurée dans Amazon Elastic Container Registry (Amazon ECR). Pour voir un exemple, consultez la rubrique [Politiques de référentiel Amazon ECR](images-create.md#configuration-images-permissions). Voici un exemple de stratégie d’autorisations avec une portée limitée. Elle permet à un utilisateur de créer et gérer des fonctions Lambda nommées avec un préfixe distinct (`intern-`) et configurées avec un rôle d’exécution désigné. **Example Stratégie de développement des fonctions** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadOnlyPermissions", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:GetEventSourceMapping", "lambda:GetFunction", "lambda:GetFunctionConfiguration", "lambda:GetFunctionCodeSigningConfig", "lambda:GetFunctionConcurrency", "lambda:ListEventSourceMappings", "lambda:ListFunctions", "lambda:ListTags", "iam:ListRoles" ], "Resource": "*" }, { "Sid": "DevelopFunctions", "Effect": "Allow", "NotAction": [ "lambda:AddPermission", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:*:*:function:intern-*" }, { "Sid": "DevelopEventSourceMappings", "Effect": "Allow", "Action": [ "lambda:DeleteEventSourceMapping", "lambda:UpdateEventSourceMapping", "lambda:CreateEventSourceMapping" ], "Resource": "*", "Condition": { "ArnLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } } }, { "Sid": "PassExecutionRole", "Effect": "Allow", "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:GetRolePolicy", "iam:PassRole", "iam:SimulatePrincipalPolicy" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" }, { "Sid": "ViewLogs", "Effect": "Allow", "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*" } ] } ``` Les autorisations de la stratégie sont organisées en déclarations reposant sur les [ressources et conditions](lambda-api-permissions-ref.md) qu’elles prennent en charge. + `ReadOnlyPermissions` – La console Lambda utilise ces autorisations lorsque vous parcourez et affichez les fonctions. Les conditions ou modèles de ressources ne sont pas pris en charge. ``` "Action": [ "lambda:GetAccountSettings", "lambda:GetEventSourceMapping", "lambda:GetFunction", "lambda:GetFunctionConfiguration", "lambda:GetFunctionCodeSigningConfig", "lambda:GetFunctionConcurrency", "lambda:ListEventSourceMappings", "lambda:ListFunctions", "lambda:ListTags", "iam:ListRoles" ], "Resource": "*" ``` + `DevelopFunctions` – Utilisez toute action Lambda qui s’exécute sur des fonctions ayant le préfixe `intern-`, à l’exception de `AddPermission` et de `PutFunctionConcurrency`. `AddPermission` modifie la [politique basée sur les ressources](access-control-resource-based.md) de la fonction, ce qui peut avoir des conséquences en matière de sécurité. `PutFunctionConcurrency` réserve la capacité de mise à l’échelle pour une fonction, et peut retirer de la capacité à d’autres fonctions. ``` "NotAction": [ "lambda:AddPermission", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:*:*:function:intern-*" ``` + `DevelopEventSourceMappings` – Gérez les mappages de source d’événement sur les fonctions qui sont préfixées avec `intern-`. Ces actions s’exécutent sur des mappages de source d’événement, mais vous pouvez les restreindre par fonction à l’aide d’une *condition*. ``` "Action": [ "lambda:DeleteEventSourceMapping", "lambda:UpdateEventSourceMapping", "lambda:CreateEventSourceMapping" ], "Resource": "*", "Condition": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } } ``` + `PassExecutionRole` – Affichez et transmettez uniquement un rôle nommé `intern-lambda-execution-role`, qui doit être créé et géré par un utilisateur avec des autorisations IAM. `PassRole` est utilisé lorsque vous attribuez un rôle d’exécution à une fonction. ``` "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:GetRolePolicy", "iam:PassRole", "iam:SimulatePrincipalPolicy" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" ``` + `ViewLogs`— Utilisez CloudWatch les journaux pour afficher les journaux des fonctions préfixées par`intern-`. ``` "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*" ``` Cette stratégie permet à un utilisateur de démarrer avec Lambda, sans nuire aux ressources des autres utilisateurs. Il ne permet pas à un utilisateur de configurer une fonction pour qu'elle soit déclenchée par d'autres services ou d'appeler d'autres AWS services, ce qui nécessite des autorisations IAM plus étendues. Cela n'inclut pas non plus l'autorisation d'accéder à des services qui ne sont pas compatibles avec les politiques à portée limitée, tels que CloudWatch X-Ray. Pour ces services, utilisez les stratégies en lecture seule afin d’accorder à l’utilisateur l’accès aux métriques et aux données de suivi. Lorsque vous configurez des déclencheurs pour votre fonction, vous devez y accéder pour utiliser le AWS service qui appelle votre fonction. Par exemple, pour configurer un déclencheur Amazon S3, vous vous devez être autorisé à utiliser les actions Amazon S3 qui gèrent les notifications de compartiment. La plupart de ces autorisations sont incluses dans la politique [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)gérée. # Octroi aux utilisateurs de l’accès à une couche Lambda Utilisez des [politiques basées sur l’identité](access-control-identity-based.md) pour autoriser des utilisateurs, des groupes d’utilisateurs ou des groupes à effectuer des opérations sur des couches Lambda. La stratégie suivante accorde à un utilisateur l’autorisation de créer des couches et de les utiliser avec des fonctions. Les modèles de ressources permettent à l'utilisateur de travailler dans n' Région AWS importe quelle version de couche, à condition que le nom de la couche commence par`test-`. **Example stratégie de développement des couches** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PublishLayers", "Effect": "Allow", "Action": [ "lambda:PublishLayerVersion" ], "Resource": "arn:aws:lambda:*:*:layer:test-*" }, { "Sid": "ManageLayerVersions", "Effect": "Allow", "Action": [ "lambda:GetLayerVersion", "lambda:DeleteLayerVersion" ], "Resource": "arn:aws:lambda:*:*:layer:test-*:*" } ] } ``` Vous pouvez également appliquer l’utilisation des couches durant la création et la configuration de la fonction avec la condition `lambda:Layer`. Par exemple, vous pouvez empêcher les utilisateurs d’utiliser les couches publiées par d’autres comptes. La stratégie ci-dessous ajoute une condition aux actions `CreateFunction` et `UpdateFunctionConfiguration` afin d’exiger que toutes les couches spécifiées proviennent du compte `123456789012`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ConfigureFunctions", "Effect": "Allow", "Action": [ "lambda:CreateFunction", "lambda:UpdateFunctionConfiguration" ], "Resource": "*", "Condition": { "ForAllValues:StringLike": { "lambda:Layer": [ "arn:aws:lambda:*:123456789012:layer:*:*" ] } } } ] } ``` ------ Pour que la condition s’applique, vérifiez qu’aucune autre déclaration n’accorde d’autorisation utilisateur à ces actions.