AWS Lambda
Manuel du développeur

Stratégies IAM basées sur l'identité pour AWS Lambda

Vous pouvez utiliser des stratégies basées sur l'identité dans AWS Identity and Access Management (IAM) afin d'accorder aux utilisateurs de votre compte l'accès à Lambda. Les stratégies basées sur l'identité peuvent s'appliquer directement aux utilisateurs, ou aux groupes et aux rôles associés à un utilisateur. Vous pouvez également accorder aux utilisateurs d'un autre compte l'autorisation d'assumer un rôle dans votre compte et d'accéder à vos ressources Lambda.

Lambda fournit des stratégies gérées qui accordent l'accès aux actions d'API de Lambda et, dans certains cas, l'accès à d'autres services utilisés pour développer et gérer des ressources Lambda. Lambda met à jour les stratégies gérées en fonction des besoins, afin de s'assurer que vos utilisateurs ont accès aux nouvelles fonctions lorsqu'elles sont publiées.

  • AWSLambdaFullAccess – Accorde un accès complet aux actions et à d'autres services AWS Lambda utilisés pour développer et gérer les ressources Lambda.

  • AWSLambdaReadOnlyAccess : accorde l'accès en lecture seule aux ressources AWS Lambda.

  • AWSLambdaRole – Accorde les autorisations requises pour appeler les fonctions Lambda.

Les stratégies gérées accordent l'autorisation aux actions d'API sans pour autant restreindre les fonctions ou les couches 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.

Développement des fonctions

Voici un exemple de stratégie d'autorisations avec une portée limitée. Elle permet à un utilisateur de créer et de gérer des fonctions Lambda nommées avec un préfixe distinct (intern-) et configurées avec un rôle d'exécution distinct.

Exemple Stratégie de développement des fonctions

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ReadOnlyPermissions", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "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": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } } }, { "Sid": "PassExecutionRole", "Effect": "Allow", "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" }, { "Sid": "ViewExecutionRolePolicies", "Effect": "Allow", "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*" }, { "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 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:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "iam:ListRoles" ], "Resource": "*"
  • DevelopFunctions – Utilisez n'importe quelle action Lambda qui s'exécute sur les fonctions ayant le préfixe intern-, à l'exception de AddPermission et de PutFunctionConcurrency. AddPermission modifie la stratégie basée sur les ressources de la fonction et 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 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 pour une fonction.

    "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
  • ViewExecutionRolePolicies – Affichez les stratégies gérées fournies par AWS qui sont attachées au rôle d'exécution. Vous pouvez ainsi afficher les autorisations de la fonction dans la console, mais vous ne pouvez pas afficher les stratégies qui ont été créées par d'autres utilisateurs dans le compte.

    "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*"
  • ViewLogs – Utilisez CloudWatch Logs pour afficher les journaux relatifs aux fonctions préfixées avec 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. Elle ne permet pas à un utilisateur de configurer une fonction qui doit être déclenchée par d'autres services AWS ou appeler ces derniers ; pour cela, des autorisations IAM plus étendues sont nécessaires. Elle n'inclut pas d'autorisation d'accès aux services qui ne prennent pas en charge les stratégies de portée limitée, telles que CloudWatch et 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 être autorisé à utiliser le service AWS qui appelle votre fonction. Par exemple, pour configurer un déclencheur Amazon S3, vous avez besoin d'une autorisation d'accès aux actions Amazon S3 afin de gérer les notifications de compartiment. Plusieurs de ces autorisations sont incluses dans la stratégie gérée AWSLambdaFullAccess. Vous trouverez des exemples de stratégies dans le référentiel GitHub de ce guide.

Développement et utilisation des couches

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'importe quelle région AWS, avec n'importe quelle version de couche, à condition que le nom de la couche commence par test-.

Exemple 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.

{ "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.

Rôles entre comptes

Vous pouvez appliquer l'une des stratégies et des déclarations précédentes à un rôle, que vous pouvez ensuite partager avec un autre compte pour lui attribuer l'accès à vos ressources Lambda. Contrairement à un utilisateur IAM, un rôle ne dispose pas d'informations d'identification pour l'authentification. En revanche, il dispose d'une stratégie d'approbation qui spécifie qui peut endosser le rôle et utiliser ses autorisations.

Vous pouvez utiliser les rôles entre comptes pour donner aux comptes que vous approuvez l'accès aux actions et aux ressources Lambda. Si vous souhaitez simplement accorder l'autorisation d'appeler une fonction ou d'utiliser une couche, utilisez plutôt des stratégies basées sur les ressources.

Pour plus d'informations, consultez Rôles IAM dans le IAM Guide de l'utilisateur.