Allow only what your Lambda code needs
Tags: aws, serverless, lambdafunctions, iamrole
Published: 2022-07-31 17:55:00

While executing [AWS Lambda functions](https://aws.amazon.com/lambda/) would need IAM permissions to access either for *READ* or *WRITE* actions. For this you need to map an [IAM Role](https://aws.amazon.com/iam/features/manage-roles/) with an associated IAM Policy.

As a best practice, we would follow *least privilege permission* but often times when you are in the development phase, you are testing multiple different things and end up having too many permissions. 

### Understanding your Lambda's permission
![Lambda permission tab](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/14esp6dc2ma1xbw42ncf.png)
From AWS Lambda functions console, you can view and managed the permissions needed for your Lambda function. This is available in *Permissions* tab under *Configuration* tab. This hyperlinks to the IAM Role where you can modify the different permissions.

![Lambda functions console - permission by resource](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2rv2xbahrybes5957h9e.png)
AWS Lambda functions console gives resource based overview of permissions with a summary of actions and resources. This will give you an understanding that this Lambda function can create *Amazon CloudWatch log groups*. 
![Lambda function console - Resource based policy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6pklmwgca1gwkuy7vp31.png)
The permissions tab provides visibility on what other sources can trigger this specific Lambda function. When the source of Lambda function trigger is SNS, you can view the resource policy document which allows `lambda:InvokeFunction` action with the `AWS:SourceArn` of the SNS topic.

### Why least-privilege permission
Some questions that I've got in the past are - 
> You have already access controlled your IAM users, why another level of access control for Lambda functions?

As legit the question sounds, it's really a lack of understanding of the concept of *least-privilege* itself. Well, there are certain operations which are done manually or viewed on the console which is where IAM user level privilege comes into play. But when IAM roles are used for accessing different AWS Services or Resources from AWS Lambda Functions programmatically with AWS SDK or different sources for Lambda triggers or Lambda destinations. When this is done, IAM roles for that specific Lambda function come into action! 
In this scenario, if IAM user doesn't have permission to delete a specific *SNS topic*, and your Lambda function's IAM role has a generic permission of `Allow: sns:*`, then with *AWS SDK*, the IAM user can deploy a Lambda function code which can use `deleteTopic()` with the *topic ARN* and successfully delete the topic.

> Why not have a generic IAM role for all Lambda functions?

This does make your maintenance of different IAM roles easier but what happens is when you have dangerous code which is not intended for that Lambda function comes into picture like in the above scenario where `deleteTopic()` method should not be in you Lambda code but ends up there. In such scenarios, IAM execution role of your Lambda becomes a defensive layer! So each Lambda function with a dedicated IAM execution role will only allow what is needed for that Lambda function.

> Should I go with managed Policies? 

AWS Managed Policies are a great way to begin with, while this does address most of the cases but sometimes you would need have your own IAM policy defined.

```
ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess
        - arn:aws:iam::aws:policy/CloudWatchFullAccess
```
For most of your use-case, you may not need *full access* to different AWS resources so choosing which managed policy works for is the decision on your part.

```
Policies:
        -
          PolicyName: StepFunctionsInvokeLambda
          PolicyDocument: 
            Version: "2012-10-17"
            Statement: 
              - 
                Effect: Allow
                Action: lambda:InvokeFunction
                Resource: !GetAtt Iterator.Arn
```

### Conclusion
Recently, I did get some queries about why securing your Lambda code with appropriate IAM permissions which motivated me to author this blog post. Following the best practices approach, it is always good to go with *least privileges* and dedicated IAM execution role for each of your Lambda functions.