Extra policy is attached to Lambda's execution role for SQS event

[gheibia]

Description:

When creating a Lambda with a SQS trigger, by default, "AWSLambdaSQSQueueExecutionRole" policy is attached to the lambda's execution role which gives access to DeleteMessage from ALL queues.

Steps to reproduce:

Use the following snippet to create a function with an SQS trigger.

MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: ....
      CodeUri: ....
      Policies:
      - AWSXrayWriteOnlyAccess
      - AWSLambdaBasicExecutionRole
      - SQSPollerPolicy:
          QueueName: !GetAtt MyQueue.QueueName
      Events:
        TheSQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt MyQueue.Arn

Observed result:

Lambda's execution role has the AWSLambdaSQSQueueExecutionRole policy attached to it, which gives access to delete messages from all queues:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Expected result:

I'm expecting this to create an execution role to which only 3 policies are attached, since I only specified 3 policies.

[gheibia]

@xazhao Could I know why this is tagged as a feature, please? This seems like a bug to me. That is, a policy gets attached where it shouldn't be.

[xazhao]

@gheibia I believe we attach AWSLambdaSQSQueueExecutionRole by default in case some users forgot to attach it. I tagged it as a feature because if we simply fix it, it might break other's template. A safer workaround would be finding a way to disable attach policies by default.

Also I will be talking about this issue with the team. I will update the labels once I have some better ideas from the team.

[gheibia]

Thanks for the update @xazhao. To me attaching a policy like that violates the principle of least privilege. That is, without my consent, my function is receiving a wide open access (DELETE, of all access rights) to all queues.

[aschieb]

@xazhao I would also really appreciate to get a possibility to not attach the AWSLambdaSQSQueueExecutionRole role.
Our current approach is defining our own role in the template.yaml, but this really bloats up the file. Instead of adding 3 LOC, we need to add about 25 LOC to the template file.

[SimonCMoore]

When SAM is creating roles for event sources to the serverless function it is currently not scoping them to that eventsource (even when in addition the customer supplies appropriately scoped policies). This falls into the class of changes that ideally we should do but may not be able to do for fear of unexpectedly breaking customers who are relying on this behaviour (and probably not supplying any policies). I will bring this back to the team with a suggestion that we provide a way to achieve the desired result without breaking existing customers.

[vazkir]

Is there any update on this issue?

[ssenchenko]

We can't simply narrow down the resource constraint as it might break existing apps.
The other solution would be to add a new field which allow for a narrow permissions on creation. However it's not a very nice solution.
Moving this issue to discussions to wee if there would be votes in favour of adding a new property

[mew1033]

I just ran into this as well. I don't know how it can be solved since it's already out in the wild. But I'd love to see a possible change where SAM doesn't create this overly permissive role.