Picture this: you’ve just finished writing your Lambda function, and everything seems ready to go. You hit deploy, trigger the function... and nothing happens. Then it hits you—permissions. That nagging afterthought you were sure you’d figure out later is now the only thing standing between you and a working application. Did you configure that policy correctly? Does the event source have permission to invoke the function? What about the execution role—did you forget something? Without proper preparation, permission problems can turn a simple deployment into a debugging nightmare.
In this blog post, I'll guide you through setting up permissions for your AWS Lambda functions. We'll cover IAM policies in detail, and I'll share a handy shortcut using AWS SAM to streamline the process.
Before we dive in, let’s quickly review how Lambda functions work in an event-driven application. Lambda functions are invoked when the corresponding event source triggers the Lambda function. However, before the event source can trigger the function, it needs the correct AWS Identity and Access Management (IAM) policy configured. This ensures that your Lambda function can interact with the necessary services before the event source even fires. Then, you'll need to ensure that the Lambda execution role is set up properly so the function can interact with other services after the function is invoked.
Identity-based Policies
There are two different types of IAM policies you can add to your Lambda function. The first is an identity-based policy. Identity-based policies are used to grant users in your account access to Lambda. They can apply to users directly, or to groups and roles that are associated with a user. Think of identity-based policies as VIP passes you hand out to people who need to work with your Lambda function.
For example, you can attach the policy to the IAM user named John, stating that he is allowed to perform the Amazon EC2 RunInstances action. The policy could further state that John is allowed to get items from an Amazon DynamoDB table named MyCompany. You can also allow John to manage his own IAM security credentials.
The beauty of these policies is how flexible they are - you can make them as broad or specific as you need, depending on what your team members need to get their jobs done.
Resource-based Policies
The second type of IAM policy you can add to your Lambda function is a resource-based policy.
Instead of attaching these to users, you stick them directly onto AWS resources themselves. You specify who has access to the resource, and what actions they can perform on it.
For example, you can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, and VPC endpoints.
One feature that makes this process much easier is that whenever you create a new Lambda function, AWS automatically sets up a special IAM role for it. To view or edit the policy, navigate to the Lambda function you created, and choose the Configuration tab. Then choose Permissions from the left panel. You can see the resource-based policy below for this Lambda function. This role has permission to create an Amazon CloudWatch Log Group for the Lambda invocation, as well as create log streams and put events to those streams.
To give other services access to your Lambda function, choose the Role name. Choosing this link will navigate you to the IAM console.
Choose the policy name and then choose Edit Policy.
Here, you can add permissions for any AWS service to access your Lambda function. (For the full list of permissions, see the AWS Documentation).
You can choose to configure permissions in the visual editor or write the configuration in JSON. This is an example of a resource-based permission policy to allow Lambda to get an object from the S3 bucket named mybucket-image-processing. It also allows Lambda to put an object into an S3 bucket named mybucket-image-processing-resized.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::mybucket-image-processing/*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::mybucket-image-processing-resized/*"
}
]
}
AWS Lambda execution role
Now that we’ve established security for our Lambda function before it’s invoked, let’s go through Lambda security after it’s invoked. When you create a Lambda function, you assign it an execution role, and whenever the function runs, AWS temporarily assumes that role to determine what actions it can perform.
For example, let’s say every time your Lambda function is triggered, it sends a notification via SNS. In this case, the Lambda execution role needs to have the correct permissions to publish to SNS. Without this permission, your function won’t be able to perform the intended action, even if the rest of the setup is correct. You can view and edit what resources your Lambda function has access to by looking at the Resource summary section in the Lambda console below.
By carefully configuring the execution role and adhering to the principle of least privilege, you minimize the risk of unauthorized access or unintended actions. Regularly reviewing and auditing these permissions, leveraging monitoring tools like AWS CloudWatch, and implementing additional security measures such as VPC restrictions or encryption can further enhance your Lambda security posture.
Benefits of configuring permissions with AWS Serverless Application Model
In the previous sections, we explored how to manually configure IAM policies and Lambda execution roles. However, if you prefer to simplify the process, you can use AWS SAM as a shortcut. With the AWS Serverless Application Model (AWS SAM), permissions for your event source to invoke your Lambda function are automatically created when you deploy the SAM template.
For instance, the following SAM template sets up an Amazon API Gateway API, a Lambda function, and a DynamoDB table, with API Gateway serving as the event source for the Lambda function. Upon deployment, SAM automatically grants API Gateway the necessary permissions to invoke the function. This not only saves time but also reduces the risk of configuration errors!
This is another reason why I love using Infrastructure as Code for cloud deployments!
Conclusion
When you add a Lambda function to your serverless application, there are two important security principles that are critical to understand: IAM policies before your Lambda function is invoked, and Lambda execution roles after your Lambda function is invoked. It’s also a great idea to use SAM when you deploy Lambda functions because the permissions for your event source to invoke your Lambda function are created automatically for you when you deploy the SAM template.
Thanks for reading! For all things cloud, follow me by clicking the follow button at the top of this page, subscribe to my newsletter below, and follow me on Twitter!
