0
votes

I haven’t been able to find the answer to this question related to serverless framework and being unable to deploy the lambda but please let me know if I have missed it.

My scenario is I have my lambda in account 0001 and I need to read messages from an SQS queue in AWS account 0002. The role “interestingrole” is created in account 0001 via Terraform and I would prefer to keep it that way unless there's a reason to do it via serverless. The SQS queue in account 0002 has a trust relationship set up for the role "interestingrole" in account 0001. The policy looks like this in account 0001

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowMyRequest”,
“Effect”: “Allow”,
“Action”: [
“sqs:ReceiveMessage”,
“sqs:GetQueueUrl”,
“sqs:GetQueueAttributes”,
“sqs:DeleteMessageBatch”,
“sqs:DeleteMessage”,
“sqs:ChangeMessageVisibilityBatch”,
“sqs:ChangeMessageVisibility”
],
“Resource”: “arn:aws:sqs:us-east-1:0002:interesting-queue”
},

In account 0002 a trust relationship has been set up with the role created in account 0001 (same as where the lambda runs). I don’t control account 0002.

If I in my serverless.yml creates a queue with the same name and set the resource as 0001 instead of 0002 it will deploy just fine and also works to read messages from that queue but if I use account 0002 I get the deployment error " An error occurred: EventHandlerEventSourceMappingSQSCinterestingqueue - Invalid request provided: The provided execution role does not have permissions to call ReceiveMessage on SQS (Service: Lambda, Status Code: 400"

Do I need to set up AssumeRole in my serverless.yml or refer to the role I have created “interestingrole” in some other way? I couldn’t find an example for this particular case where my role is in the account I control and execute the lambda (0001) but the resource I want to access is in a different account.

I don’t have iAmRoleStatement configured for the queue currently.

serverless.yml

functions:
eventHandler:
handler: src/lambda.handler
events:
- sqs: “arn:aws:sqs:us-east-1:0002:interesting-queue”

Thank you!

1
What is the SQS resource-policy? It should allow access to the lambda execution role from the first account. The policy you've posted, is it for SQS queue policy? If so, it does not have Principle? - Marcin
@Marcin no it does not have Principle. A different team in the organization have specified how they want the role to be set up. - Magnus Lassi
If I understand your scenario, serverless framework really isn't any part of this. Your Lambda function in account 0001 should have whatever permissions it needs for local resources (at least AWSLambdaBasicExecutionRole) plus permission for sts:AssumeRole on the ARN of interestingrole. The Lambda function, when executed, should assume interestingrole which will give it STS credentials. Use those STS credentials to create a new SDK service object (e.g. boto3 client) to make SQS API calls against account 0002's SQS queue. - jarmod

1 Answers

0
votes

For anyone else that runs into this issue, I resolved it by specifying the custom IAM role I want the lambda to use in the serverless.yml:

provider:
  name: aws
  role: arn:aws:iam:0002:role/interestingrole

This has drawbacks since the iamRoleStatements doesn't apply any longer so you have to add log permissions and other permissions your lambda needs to this custom role but for my very narrow use case this was acceptable.

You can see more here under the section "Custom IAM Roles" https://www.serverless.com/framework/docs/providers/aws/guide/iam/ .