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

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 à appeler votre fonction en votre nom.

Pour les fonctions Lambda, vous pouvez accorder une autorisation de compte afin d'appeler 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'appel à un service AWS qui appelle une fonction en réponse à une activité dans votre compte.

Pour afficher la stratégie basée sur les ressources d'une fonction
  1. Ouvrez la page Functions (Fonctions) de la console Lambda.

  2. Choisissez une fonction.

  3. Sélectionnez Configuration (Configuration), puis Permissions (Autorisations).

  4. 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 à appeler une fonction nommée my-function pour un compartiment nommé my-bucket dans le compte 123456789012.

    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 pouvez mettre à jour les stratégies basées sur une ressource uniquement pour les ressources Lambda concernées par les actions d'API AddPermission et 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.

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

Lorsque vous utilisez un service AWS pour appeler 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 à appeler 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'appeler. 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 à 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

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 appeler l'API lambda:Invoke pour la fonction, mais ne restreint pas la rubrique Amazon SNS qui déclenche l'appel. 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 source-account avec votre ID de compte 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 à 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 AWS CLI AddPermission 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'appel 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'appel 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:PrincipalOrgID dans le guide de l'utilisateur AWS Identity and Access Management.

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'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 111122223333 --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 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

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 appelle 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é à appeler 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.

API inter-comptes

Actuellement, Lambda ne prend pas en charge les actions entre comptes pour l'ensemble de ses API via des politiques basées sur les ressources. Les API suivantes sont prises en charge :

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. 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 111122223333 --version-number 1 --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-2:123456789012:layer:xray-sdk-nodejs:1"}

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 octroyer une autorisation à tous les comptes AWS, utilisez * pour le mandataire 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