1 Answer
- Newest
- Most votes
- Most comments
0
The best approach, taking into consideration the least privilege principal, is to create an IAM Role per function. You did not mention this, but I assume you have more than one queue, more than one bucket, etc. and each function needs to access different queues/buckets. By having a role per function you can grant the function access only to the resources it actually need. Otherwise you will need to use : which is not recommended.
If you use infrastructure as code (as you should) such as SAM, CloudFromation, CDK, etc., the role creation should be part of the function creation.
Relevant content
- Accepted Answerasked 10 months ago
- asked a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a month ago
Thanks for your reply.
Yes, we are having multiple SQS and S3 bucket etc. in our application and we need to access them from lambda functions.
If we consider the least privilege principal, and create an IAM Role per function then in such case we will not be able to re-use existing role created for same access in other lambda function. For E.g, We have lambda A and lambda B For lambda A (We provide access to SQS push and S3 read) using separate role function wise For lambda B (We also requires same access of SQS push and S3 read considering same queue and bucket) Then, Will be able to use role created to lambda A for lambda B? Or it would be fine to create different role for both lambda with same kind of access permission?
Regarding infrastructure as code we use 'CloudFromation', which I forgot to mention in my question details actually.
Even though both function TODAY need the same permissions, things can change in the future. I would still recommend to use one role per function.
If you make sure to create the roles in the same stack you create your functions, it make management of the roles easier. Also, if you use the Serverless Application Model (SAM) instead of using CloudFormation directly, you can define the role as part of the function definition itself.
Thanks for your valuable response on helping us to identify best approach based on our use case.