Setting Permissions to AWS Lambda

We set permissions using IAM. It is good to know that AWS lambda uses decoupled model to set the permissions.

Lambda uses 2 types of IAM Permissions

• Invoke permission: To Invoke lambda from other callers like API Gateway, SNS, SQS .etc..
• Execute Permissions: Permissions to execute the lambda code, like If lambda needs to connect to S3 bucket.

There are few best practices I can suggest for creating the roles for lambda

• Each lambda should have its own role instead of using same role across all lambda functions. As Needs of each lambda might be different. If each function has its own role then it is loosely decoupled IAM Permissions.
• Avoid setting wild card permissions to lambda. Keep permissions as restrictive as possible.
• Storing tokens and sensitive data should be done only in Environment variables and not hardcoded.
• Make use of KMS to store sensitive data by encryption. Also never log these values to console.
• If you are using lambda with in VPC it is good to use least privilege's security group, lambda function specific subnets and network configuration.

Bonus :

API Gateway also can be controlled by below methods while invoking Lambda

• API keys and usage plans
• Client Certifications
• CORS Headers
• API Gateway Resource polices
• IAM Polices
• Lambda Authorizers
• Coginto User Pool Authorizers
• Federated Identity Access using Cognito

Also ensure appropriate access control to CI/CD tools with restrictive access to modify the production environment.