Utilisation de politiques IAM basées sur l'identité dans Lambda - AWS Lambda

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.

Utilisation de politiques IAM basées sur l'identité dans Lambda

Vous pouvez utiliser des politiques basées sur l'identité dans AWS Identity and Access Management (IAM) pour autoriser les utilisateurs de votre compte à accéder à 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'endosser un rôle de votre compte et d'accéder à vos ressources Lambda. Cette page montre un exemple de la façon dont les politiques basées sur l'identité peuvent être utilisées pour le développement de fonctions.

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_FullAccess— Accorde un accès complet aux actions Lambda et aux autres AWS services utilisés pour développer et gérer les ressources Lambda. Cette politique a été créée en reprenant la politique AWSLambdaFullAccessprécédente.

  • AWSLambda_ReadOnlyAccess— Accorde un accès en lecture seule aux ressources Lambda. Cette politique a été créée en reprenant la politique AWSLambdaReadOnlyAccessprécédente.

  • AWSLambdaRole— Accorde l'autorisation d'invoquer 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.

Rédaction d'un exemple de politique accordant des autorisations aux utilisateurs pour une fonction

Utilisez des stratégies basées sur une identité pour autoriser des utilisateurs à effectuer des opérations sur des fonctions Lambda.

Note

Pour une fonction définie comme une image de conteneur, l'autorisation utilisateur d'accéder à l'image DOIT être configurée dans le registre de conteneur Amazon Elastic. Pour un exemple, consultez Autorisations Amazon ECR.

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

Exemple 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": { "StringLike": { "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 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 stratégie basée sur une ressource 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 parintern-.

    "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 AWSLambdaFullAccessgérée. Des exemples de politiques sont disponibles dans le GitHubréférentiel de ce guide.

Rédaction d'un exemple de politique accordant des autorisations pour utiliser 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 AWS région et avec n'importe quelle version de couche, à condition que le nom de la couche commence partest-.

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.

Mise en œuvre d'un accès entre comptes avec des politiques basées sur l'identité

Vous pouvez appliquer n'importe laquelle des stratégies et déclarations précédentes à un rôle, que vous pouvez ensuite partager avec un autre compte pour lui donner accès à vos ressources Lambda. Contrairement à un utilisateur, 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 des rôles entre comptes pour donner à des comptes de confiance l'accès à des actions et 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 de plus amples informations, veuillez consulter Rôles IAM dans le Guide de l'utilisateur IAM.