AWS Lambda Permissions: Execution Role and Resource-based Policies
In this article, we are going to learn AWS Lambda permissions; Execution role and Resource-based policies.
AWS has a service that handle permissions, which name is AWS Identity and Access Management (IAM). So We can use “AWS Identity and Access Management (IAM)” in order to manage access to the Lambda functions.
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
We can manage permissions in a permissions policy that you can apply to IAM users, groups, or roles in order to execute Lambda functions with policy definitions. So basically Lambda function also has a policy which name is Execution Role.
Lambda Execution Role
Lambda Execution Role grants permission to access AWS services and resources. By default Lambda function needs access to Amazon CloudWatch Logs for log streaming. So that means when you create any lambda function, by default it comes with Execution role which includes Amazon CloudWatch Logs.
So if Lambda function will accesses services with the AWS SDK, we should grant it permission to call aws resources in the execution role. For example if our lambda function access to dynamodb to perform crud operations, we should give required permission in the execution role of the lambda function.
As the same way, Lambda also uses the execution role to get permission to read from event sources when you use an event source mapping to trigger your function. For example if our lambda function read queue record from the SQS, we should give required permission in the execution role of the lambda function. There is also another type of permission of Lambda functions which is the Resource-based policy.
We will use resource-based policies to give other AWS services permission to use our Lambda function. For example When an AWS service like Amazon S3 calls our Lambda function, the resource-based policy gives it access.
If we summarize permissions on AWS Lambda, we will use 2 type of permissions when working with AWS Lambda;
1- Lambda Execution Role
2- Resource-based policy
Lambda execution role is an IAM role that Lambda has permissions to assume when invoking lambda function. We need to select or create an execution role when creating a new lambda function, and after that we can also modify the policies associated with the IAM role using the IAM.
AWS managed policies for Lambda features
AWS has also managed policies for Lambda Execution Roles. You can see the list of managed Lambda Execution Roles here;
https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html
Examples:
- AWSLambdaBasicExecutionRole — Lambda started tracking changes to this policy.
- AWSLambdaBasicExecutionRole grants permissions to upload logs to CloudWatch.
- AWSLambdaDynamoDBExecutionRole — Lambda started tracking changes to this policy.
- AWSLambdaDynamoDBExecutionRole grants permissions to read records from an Amazon DynamoDB stream and write to CloudWatch Logs.
You can use these managed policies, you don't need to create a new execution role if these roles cover your business requirements.
AWS Lambda Resource-based Policy
We have another permissions type for Lambda functions which is Resource-based policy. We use Resource-based policy when any AWS service invokes Lambda function sync or asynchronous way.
Resource-based policies let you grant usage permission to other AWS accounts or organizations on a per-resource basis. We also use a resource-based policy to allow an AWS service to invoke your function on your behalf.
For example, if we create an API Gateway that targets to Lambda function,
we should add resource-based policy permission to invoke lambda function from API Gateway. This is a sync invocation example that API Gateway invokes to lambda function synchronously, so we should add Resource-based policy.
If we give example for asynchronous case, Amazon S3 upload event triggers to lambda function asynchronously, so we should also add Resource-based policy into our Lambda function grants S3 invocation.
Here you can find Example Resource-based policy
https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html
{
“Version”: “2012–10–17”,
“Id”: “default”,
“Statement”: [
{
“Sid”: “lambda-allow-s3-my-function”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “s3.amazonaws.com”
},
“Action”: “lambda:InvokeFunction”,
“Resource”: “arn:aws:lambda:us-east-2:123456789012:function:my-function”,
“Condition”: {
“StringEquals”: {
“AWS:SourceAccount”: “123456789012”
},
“ArnLike”: {
“AWS:SourceArn”: “arn:aws:s3:::my-bucket”
}
}
}
]
}We can set Resource-based policy from the AWS management console
Choose a function. Choose Configuration and then choose Permissions.
The above example shows a statement that allows Amazon S3 to invoke a function named my-function for a bucket named my-bucket in account 123456789012. As you can see that we have understood AWS Lambda permissions; Execution role and Resource-based policies.
Step by Step Design AWS Architectures w/ Course
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
In this course, we will learn almost all the AWS Serverless Services with all aspects. We are going to build serverless applications with using AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Cognito, Amazon S3, Amazon SNS, Amazon SQS, Amazon EventBridge, AWS Step Functions, DynamoDB and Kinesis Streams. This course will be 100% hands-on, and you will be developing a real-world application with hands-on labs together and step by step.
Source Code
Get the Source Code from Serverless Microservices GitHub — Clone or fork this repository, if you like don’t forget the star. If you find or ask anything you can directly open issue on repository.
