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 stratégies basées sur les ressources pour Lambda
Lambda prend en charge les stratégies d’autorisations basées sur une ressource pour les fonctions et les couches Lambda. Les politiques basées sur les ressources vous permettent d’accorder des autorisations d’utilisation à d’autres comptes ou organisations AWS en fonction de chaque ressource. Vous pouvez également utiliser une stratégie basée sur les ressources pour autoriser un service AWS à invoquer votre fonction en votre nom.
Pour les fonctions Lambda, vous pouvez accorder une autorisation de compte afin d’invoquer ou de gérer une fonction. Vous pouvez également utiliser une seule politique basée sur les ressources pour accorder des autorisations à une organisation entière dans AWS Organizations. Vous pouvez également utiliser des politiques basées sur les ressources pour accorder une autorisation d’invocation à un service AWS qui invoque une fonction en réponse à une activité dans votre compte.
Pour afficher la stratégie basée sur les ressources d’une fonction
Ouvrez la page Functions
(Fonctions) de la console Lambda. -
Choisissez une fonction.
-
Sélectionnez Configuration (Configuration), puis Permissions (Autorisations).
-
Faites défiler la page vers le bas, jusqu’à Resource-based policy (Stratégie basée sur les ressources), puis choisissez View policy document (Afficher le document de stratégie). La stratégie basée sur les ressources affiche les autorisations qui sont appliquées lorsqu’un autre compte ou service AWS tente d’accéder à la fonction. L’exemple suivant montre une déclaration qui autorise Amazon S3 à invoquer une fonction nommée
my-functionpour un compartiment nommémy-bucketdans le compte123456789012.Exemple Stratégie basée sur une ressource
{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "lambda-allow-s3-my-function", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Condition": { "StringEquals": { "AWS:SourceAccount": "123456789012" }, "ArnLike": { "AWS:SourceArn": "arn:aws:s3:::my-bucket" } } } ] }
Pour les couches Lambda, vous ne pouvez utiliser une stratégie basée sur les ressources que sur une version de couche spécifique, non sur la totalité de la couche. Outre les stratégies qui accordent l’autorisation à un seul compte ou à plusieurs comptes, vous pouvez aussi, pour les couches, accorder une autorisation à tous les comptes d’une organisation.
Note
Vous ne pouvez mettre à jour les politiques basées sur les ressources pour les ressources Lambda que dans le cadre des actions et de l'AddPermissionAPI. AddLayerVersionPermission Actuellement, vous ne pouvez pas créer de stratégies pour vos ressources Lambda dans JSON, ou utiliser des conditions qui ne correspondent pas aux paramètres de ces actions.
Les stratégies basées sur les ressources s’appliquent à une seule fonction, version ou version de couche ou à un seul alias. Elles accordent l’autorisation à un ou à plusieurs services et comptes. Pour les comptes approuvés qui doivent pouvoir accéder à plusieurs ressources ou pour utiliser les actions d’API non prises en charge par les stratégies basées sur les ressources, vous pouvez utiliser les rôles entre comptes.
Rubriques
Actions d’API prises en charge
Les actions de l’API Lambda suivantes prennent en charge les politiques basées sur les ressources :
Octroi à la fonction de l’accès aux services AWS
Lorsque vous utilisez un service AWS pour invoquer votre fonction, vous accordez l’autorisation dans une instruction sur une stratégie basée sur les ressources. Vous pouvez appliquer la déclaration à l’ensemble de la fonction à invoquer ou à gérer, ou limiter la déclaration à une seule version ou un seul alias.
Note
Lorsque vous ajoutez un déclencheur à la fonction à l’aide de la console Lambda, celle-ci met à jour la stratégie basée sur une ressource de la fonction afin d’autoriser le service à l’invoquer. Pour accorder des autorisations à d’autres comptes ou services non disponibles dans la console Lambda, vous pouvez utiliser l’AWS CLI.
Ajoutez une déclaration avec la commande add-permission. La déclaration de stratégie basée sur les ressources la plus simple autorise un service à invoquer une fonction. La commande ci-après accorde à Amazon SNS l’autorisation d’invoquer une fonction nommée my-function.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id sns \ --principal sns.amazonaws.com --output text
Vous devriez voir la sortie suivante:
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
Amazon SNS peut ainsi invoquer l’API lambda:Invoke pour la fonction, mais ne restreint pas la rubrique Amazon SNS qui déclenche l’invocation. Afin de vous assurer que votre fonction est invoquée uniquement par une ressource spécifique, spécifiez l’ARN (Amazon Resource Name) de la ressource avec l’option source-arn. La commande ci-après autorise uniquement Amazon SNS à invoquer la fonction pour des abonnements à une rubrique nommée my-topic.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id sns-my-topic \ --principal sns.amazonaws.com --source-arn arn:aws:sns:us-east-2:123456789012:my-topic
Certains services peuvent invoquer des fonctions dans d’autres comptes. Cela ne pose pas de problème si vous spécifiez un ARN source qui contient votre ID de compte. Pour Amazon S3, cependant, la source est un compartiment dont l’ARN ne contient pas d’ID de compte. Il est possible que vous puissiez supprimer le compartiment et qu’un autre compte crée un compartiment du même nom. Utilisez l’option source-account avec votre ID de compte pour vous assurer que seules les ressources de votre compte peuvent invoquer la fonction.
aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id s3-account \ --principal s3.amazonaws.com --source-arn arn:aws:s3:::my-bucket-123456--source-account123456789012
Octroi de l’accès à la fonction à une organisation
Pour accorder des autorisations à une organisation dans AWS Organizations, spécifiez l’ID de l’organisation en tant que principal-org-id. La commande AddPermission AWS CLI suivante accorde un accès d'appel à tous les utilisateurs de l'organisation o-a1b2c3d4e5f.
aws lambda add-permission --function-name example \ --statement-id PrincipalOrgIDExample --action lambda:InvokeFunction \ --principal * --principal-org-id o-a1b2c3d4e5f
Note
Dans cette commande, Principal est *. Cela signifie que tous les utilisateurs de l’organisation o-a1b2c3d4e5f obtiennent des autorisations d’invocation de fonction. Si vous spécifiez un compte ou un rôle AWS en tant que compte Principal, alors seul ce principal obtient des autorisations d’invocation de fonction, mais uniquement s’il fait également partie de l’organisation o-a1b2c3d4e5f.
Cette commande crée une politique basée sur les ressources qui ressemble à ce qui suit :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalOrgIDExample", "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-west-2:123456789012:function:example","Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5f" } }} ] }
Pour plus d'informations, consultez aws : PrincipalOrg ID dans le guide de AWS Identity and Access Management l'utilisateur.
Octroi de l’accès à la fonction à d’autres comptes
Pour accorder des autorisations à un autre compte AWS, spécifiez l’ID du compte comme paramètre principal. L’exemple suivant accorde au compte 111122223333 l’autorisation d’invoquer la fonction my-function avec l’alias prod.
aws lambda add-permission --function-name my-function:prod--statement-id xaccount --action lambda:InvokeFunction \ --principal111122223333--output text
Vous devriez voir la sortie suivante:
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
La stratégie basée sur les ressources accorde à l’autre compte l’autorisation d’accéder à la fonction, mais n’autorise pas les utilisateurs de ce compte à dépasser leurs autorisations. Les utilisateurs de l’autre compte doivent disposer des autorisations utilisateur correspondantes pour utiliser l’API Lambda.
Afin de limiter l’accès à un utilisateur ou à un rôle dans un autre compte, spécifiez l’ARN complet de l’identité en tant que principal. Par exemple, arn:aws:iam::123456789012:user/developer.
L’alias limite la version pouvant être invoquée par l’autre compte. L’autre compte doit alors inclure l’alias dans l’ARN de la fonction.
aws lambda invoke --function-name arn:aws:lambda:us-west-2:123456789012:function:my-function:prod out
Vous devriez voir la sortie suivante:
{ "StatusCode": 200, "ExecutedVersion": "1" }
Le propriétaire de la fonction peut alors mettre à jour l’alias afin qu’il pointe vers une nouvelle version sans que l’appelant ait besoin de modifier la façon dont il invoque votre fonction. Cela permet de s’assurer que l’autre compte n’a pas besoin de changer son code pour utiliser la nouvelle version et qu’il est uniquement autorisé à invoquer la version de la fonction associée à l’alias.
Vous pouvez accorder l’accès entre comptes pour n’importe quelle action d’API qui s’exécute sur une fonction existante. Par exemple, vous pouvez accorder l’accès à lambda:ListAliases afin qu’un compte puisse obtenir une liste des alias ou à lambda:GetFunction pour qu’il puisse télécharger le code de votre fonction. Ajoutez chaque autorisation séparément ou utilisez lambda:* pour accorder l’accès à toutes les actions pour la fonction spécifiée.
Pour accorder à d’autres comptes l’autorisation pour plusieurs fonctions ou pour des actions qui ne s’exécutent pas sur une fonction, nous vous conseillons d’utiliser des rôles IAM.
Octroi de l’accès de la couche à d’autres comptes
Pour accorder une autorisation d'utilisation de la couche à un autre compte, ajoutez une instruction à la stratégie d'autorisations de la version de la couche à l'aide de la commande add-layer-version-permission
L’exemple suivant autorise le compte 111122223333 à accéder à la version 2 de la couche bash-runtime.
aws lambda add-layer-version-permission --layer-name bash-runtime --statement-id xaccount \ --action lambda:GetLayerVersion --principal 111122223333 --version-number 2 --output text
Vous devez voir des résultats similaires à ce qui suit :
e210ffdc-e901-43b0-824b-5fcd0dd26d16 {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
Les autorisations ne s’appliquent qu’à une seule version de couche. Répétez le processus chaque fois que vous créez une nouvelle version de la couche.
Pour accorder l’autorisation à tous les comptes de l’organisation, utilisez l’option organization-id. L’exemple suivant accorde à tous les comptes d’une organisation l’autorisation d’utiliser la version 3 d’une couche.
aws lambda add-layer-version-permission --layer-name my-layer \ --statement-id engineering-org --version-number 3 --principal '*' \ --action lambda:GetLayerVersion --organization-id o-t194hfs8cz --output text
Vous devriez voir la sortie suivante:
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
Pour accorder la permission à tous les comptes AWS, utilisez * pour le principal et omettez l’ID de l’organisation. Pour plusieurs comptes ou organisations, vous devez ajouter plusieurs déclarations.
Nettoyage des stratégies basées sur les ressources
Pour afficher une stratégie basée sur les ressources d’une fonction, utilisez la commande get-policy.
aws lambda get-policy --function-name my-function --output text
Vous devriez voir la sortie suivante:
{"Version":"2012-10-17","Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]} 7c681fc9-b791-4e91-acdf-eb847fdaa0f0
Pour les versions et les alias, ajoutez le numéro de version ou l’alias au nom de la fonction.
aws lambda get-policy --function-name my-function:PROD
Pour supprimer les autorisations de votre fonction, utilisez remove-permission.
aws lambda remove-permission --function-name example --statement-id sns
Utilisez la commande get-layer-version-policy pour afficher les autorisations sur une couche.
aws lambda get-layer-version-policy --layer-name my-layer --version-number 3 --output text
Vous devriez voir la sortie suivante:
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
Utilisez remove-layer-version-permission pour supprimer des déclarations de la stratégie.
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
