Partager:
){kind=small}
Adam est un développeur et un consultant qui aime l'ultra-course, les blogs, et qui aide les autres à apprivoiser la technologie pour accomplir des choses étonnantes avec un désir insatiable de mentorat et d'aide.
Comment fonctionnent les permissions dans AWS Lambda
Lorsqu'ils travaillent avec AWS Lambda, de nombreux utilisateurs se débattent avec les autorisations utilisant d'autres services AWS. Plus précisément, comment accéder à des services tels que S3, RDS, Transcribe ou autres.
To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.
This tutorial also uses a virtual phone number. To purchase one, go to Numbers > Buy Numbers and search for one that meets your needs.
Nombreux sont ceux qui créent un nouvel utilisateur IAMet définissent AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY dans les variables d'environnement. Le SDK AWS utilise "automatiquement" ces clés ou valeurs à partir d'un fichier d'informations d'identification AWS. (Voir la documentation sur la façon dont le SDK utilise ces valeurs). Cependant, l'ajout de ces informations d'identification pour un Lambda serait une erreur.
La tentative du fichier .env empêche une application d'accéder aux services AWS depuis l'intérieur de Lambda. L'échec de la connexion est indépendant de la façon dont vous avez configuré l'utilisateur IAM.
Lorsque la fonction Lambda est déployée, les variables d'environnement indiquées ci-dessus sont générées par Lambda. Cela signifie que les valeurs du fichier .env ne sont pas définies comme prévu.
Pour en savoir plus sur le déploiement avec Serverless, consultez les articles suivants AWS Lambda avec PHP en utilisant Bref et Serverless Framework ou Python sans serveur avec AWS Lambda.
Avec les variables d'environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY définies par Lambda, les autorisations de rôle doivent également être définies lors du déploiement. Tous les services AWS sont également gérés directement dans la fonction Lambda au lieu d'un utilisateur IAM.
Voici un exemple partiel de yaml utilisant le framework Serverless pour déployer une fonction AWS Lambda.
provider:
name: aws
region: us-east-1
runtime: provided
iamRoleStatements:
- Effect: Allow
Action:
- s3:PutObject
- s3:GetObject
- s3:DeleteObject
Resource: 'arn:aws:s3:::bucket-name/*'
- Effect: Allow
Action: transcribe:*
Resource: '*'Notez le bloc iamRoleStatements dans l'exemple ci-dessus. Dans ce bloc, la Lambda est accordée s3:PutObject, s3:GetObject, et s3:DeleteObject à la ressource bucket-name et à tout ce qu'elle contient. La fonction a également accès aux transcribe:* services.
L'exemple ci-dessus est très similaire à la manière dont les autorisations IAM sont définies dans les exemples ci-dessous :
AWS IAM S3 Policy Example
AWS IAM Transcribe Policy Example
Après un déploiement réussi sur AWS Lambda, les permissions actives de la fonction peuvent être visualisées dans la console AWS. Pour ce faire, naviguez vers l'onglet Permissions de la console de la fonction.
AWS Lambda Function Permissions
De là, vous pouvez cliquer sur les autorisations de chaque service pour obtenir une description plus détaillée de la manière dont vous les avez définies.
La documentation sur les autorisations possibles pour les différents services AWS est disponible dans la Documentation sur la gestion des identités et des accès AWS. Nous vous invitons également à consulter les prochains articles contenant des exemples d'utilisation de ces autorisations.