AWS Lambda
Manuel du développeur

Utilisation de stratégies basées sur les ressources pour AWS Lambda

AWS Lambda prend en charge les stratégies d'autorisations basées sur les ressources pour les fonctions et les couches Lambda. Les stratégies basées sur les ressources permettent d'accorder une autorisation à d'autres comptes en fonction des ressources. Vous pouvez également appliquer une stratégie basée sur les ressources pour autoriser un service AWS à appeler votre fonction.

Pour les fonctions Lambda, vous pouvez accorder une autorisation de compte afin d'appeler ou de gérer une fonction. Vous pouvez ajouter plusieurs déclarations afin d'accorder l'accès à plusieurs comptes ou laisser n'importe quel compte appeler votre fonction. Pour les fonctions appelées par un autre service AWS en réponse à une activité dans votre compte, vous utilisez la stratégie pour accorder l'autorisation d'appeler le service.

Pour les couches Lambda, vous utilisez une stratégie basée sur les ressources sur une version de la couche afin que les autres comptes puissent l'utiliser. Outre les stratégies qui accordent l'autorisation à un seul compte ou à tous les comptes, vous pouvez aussi, pour les couches, accorder une autorisation à tous les comptes d'une organisation.

Note

Vous pouvez uniquement mettre à jour les stratégies basées sur des ressources pour les ressources Lambda comprises dans la portée des actions d’API AddPermission et AddLayerVersionPermission. Vous ne pouvez pas créer de stratégies pour vos ressources Lambda dans JSON ni utiliser les 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.

Attribution de l'accès à la fonction aux services AWS

Lorsque vous utilisez un service AWS pour appeler votre fonction, vous accordez l'autorisation dans une déclaration sur une stratégie basée sur les ressources. Vous pouvez appliquer la déclaration à la fonction ou la limiter à 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 les ressources de la fonction afin d'autoriser le service à l'appeler. Pour accorder des autorisations à d'autres comptes ou services non disponibles dans la console Lambda, utilisez l'interface de ligne de commande AWS.

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 à appeler une fonction. La commande ci-après accorde à Amazon SNS l'autorisation d'appeler 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 {"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 appeler la fonction, mais la rubrique Amazon SNS qui déclenche l'appel n'est pas restreinte. Afin de vous assurer que votre fonction est appelé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 à appeler 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 appeler 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 account-id pour vous assurer que seules les ressources de votre compte peuvent appeler 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-account 123456789012

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 210987654321 l'autorisation d'appeler la fonction my-function avec l'alias prod.

$ aws lambda add-permission --function-name my-function:prod --statement-id xaccount --action lambda:InvokeFunction \ --principal 210987654321 --output text {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::210987654321: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 pour utiliser l'API Lambda.

Pour limiter l'accès à un utilisateur, un groupe ou un rôle dans un autre compte, spécifiez l'ARN complet de l'identité en tant que mandataire. Par exemple, arn:aws:iam::123456789012:user/developer.

L'alias limite la version pouvant être appelé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 { "StatusCode": 200, "ExecutedVersion": "1" }

Vous pouvez ensuite mettre à jour l'alias pour qu'il pointe vers de nouvelles versions, en fonction de vos besoins. Lorsque vous mettez à jour l'alias, l'autre compte n'a pas besoin de changer son code pour utiliser la nouvelle version et il est uniquement autorisé à appeler la version que vous choisissez.

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 d'accès à plusieurs fonctions ou à des actions qui ne s'exécutent pas sur une fonction, utilisez des rôles.

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 couche avec la commande add-layer-version-permission. Dans chaque instruction, vous pouvez accorder une autorisation à un compte unique, à tous les comptes ou à une organisation.

$ aws lambda add-layer-version-permission --layer-name xray-sdk-nodejs --statement-id xaccount \ --action lambda:GetLayerVersion --principal 210987654321 --version-number 1 --output text e210ffdc-e901-43b0-824b-5fcd0dd26d16 {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::210987654321:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:xray-sdk-nodejs:1"}

Les autorisations ne s'appliquent qu'à une seule version d'une couche. Répétez la procédure 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 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 octroyer une autorisation à tous les comptes AWS, utilisez * pour le mandataire, et omettez l'ID de l'organisation. Pour plusieurs comptes ou organisations, ajoutez plusieurs instructions.

Nettoyage de 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 {"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, et remove-layer-version-permission pour supprimer les instructions de la stratégie.

$ aws lambda get-layer-version-policy --layer-name my-layer --version-number 3 --output text 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"}}}" $ aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org