Unable to add an SQS event source to a Lambda function with imported role

Describe the bug I’m unable to connect Lambda function to an SQS event source. Using 0.28.0 and 0.29.0 I’m getting an error message: Value sqs:ChangeMessageVisibilityBatch for parameter ActionName is invalid. Reason: Please refer to the appropriate WSDL for a list of valid actions.. Due to security limitations we have to provide our own pre-created lambda role. Using 0.27.0 everything is working as expected (w/ imported role). It seems that this might be a regression bug introduced in 0.28.0.

To Reproduce Here is the stack code:

    const queue = new sqs.Queue(this, "Queue", {
      visibilityTimeoutSec: 60,
      retentionPeriodSec: 172800 // 2 days
    });

    // Import existing role
    const role = iam.Role.import(this, "LambdaProcessingRole", {
      roleArn: "arn:aws:iam::1234567890:role/lambda-processing-role"
    });

    const processQueueFn = new lambda.Function(this, "ProcessQueueFunction", {
      runtime: lambda.Runtime.Python36,
      code: lambda.Code.asset("lambda_functions/python/processor"),
      handler: "process_queue.lambda_handler",
      role: role,
      timeout: 60
    });

    processQueueFn.addEventSource(new eventSources.SqsEventSource(queue, {
      batchSize: 1
    }));

And here is the policy that’s attached to lambda-processing-role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sqs:Get*",
                "sqs:List*",
                "sqs:SendMessage",
                "sqs:SendMessageBatch",
                "sqs:ReceiveMessage",
                "sqs:SetQueueAttributes",
                "sqs:TagQueue",
                "sqs:UntagQueue",
                "sqs:CreateQueue",
                "sqs:PurgeQueue",
                "sqs:DeleteMessage",
                "sqs:DeleteMessageBatch",
                "sqs:DeleteQueue",
                "sqs:AddPermission",
                "sqs:RemovePermission",
                "sqs:ChangeMessageVisibility",
                "sqs:ChangeMessageVisibilityBatch"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "SQSPolicy"
        }
    ]
}

If I run cdk deploy command using 0.27.0 everything is working as expected. However, when I use 0.28.0 and 0.29.0 with the imported lambda role this is what I’m getting back:

IAM Statement Changes
┌───┬──────────────────────────┬────────┬────────────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────┬───────────┐
│   │ Resource                 │ Effect │ Action                                                         │ Principal                                                      │ Condition │
├───┼──────────────────────────┼────────┼────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┼───────────┤
│ + │ ${Queue.Arn}             │ Allow  │ sqs:ChangeMessageVisibility                                    │ AWS:arn:aws:iam::123456789:role/lambda-processing-role         │           │
│   │                          │        │ sqs:ChangeMessageVisibilityBatch                               │                                                                │           │
│   │                          │        │ sqs:DeleteMessage                                              │                                                                │           │
│   │                          │        │ sqs:DeleteMessageBatch                                         │                                                                │           │
│   │                          │        │ sqs:GetQueueAttributes                                         │                                                                │           │
│   │                          │        │ sqs:GetQueueUrl                                                │                                                                │           │
│   │                          │        │ sqs:ReceiveMessage                                             │                                                                │           │
└───┴──────────────────────────┴────────┴────────────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────┴───────────┘
(NOTE: There may be security-related changes not in this list. See http://bit.ly/cdk-2EhF7Np)

Do you wish to deploy these changes (y/n)? y
Stack: deploying...
Stack: creating CloudFormation changeset...
 0/3 | 5:08:12 PM | CREATE_IN_PROGRESS   | AWS::SQS::QueuePolicy           | Queue/Policy (QueuePolicyD47E3C93)
 1/3 | 5:08:13 PM | CREATE_FAILED        | AWS::SQS::QueuePolicy           | Queue/Policy (QueuePolicyD47E3C93) Value sqs:ChangeMessageVisibilityBatch for parameter ActionName is invalid. Reason: Please refer to the appropriate WSDL for a list of valid actions. (Service: AmazonSQS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 06f3148d-36d8-5eec-836d-41b176c59a7e)

Expected behavior I should be able to attach Lambda function to SQS events.

Version:

• OS: Mac 10.13.6 High Sierra
• Node: 12.0.0
• Programming Language: TypeScript
• CDK Version: 0.28.0 and 0.29.0

[rix0rrr]

1. Since the role is external to the stack, the permissions are added to the queue policy instead of attached to the role. I am wondering why this is the behavior for imported roles.

You’re right, it shouldn’t be. The permissions should be added to the resource policy if the principal is in another account, and only then. I guess the API is still a little wonky, which makes this mistake too easy to make. My apologies, my understanding of IAM is progressing as this project progresses 😃

Actually, @shivlaks used 2 different terms recently which are a lot more illuminating to think about (than “policy” or “permission”), that I wonder whether we should use more widely:

• Permissions: the statements in IAM identity policy.
• Trust: the statements in a resource policy.

I’m thinking we might need to do something similar to what we do for outbound security groups (where the default is “allow all outbound traffic”, but that can be disabled for fine-grained configuration):

• On every resource with a trust policy, have a trustOwnAccount?: boolean (defaults to true).
• On every Grant, add both a permission and a trust, unless the resource has trustOwnAccount=true.

[robertd]

@eladb @rix0rrr I’m still unable to use imported role with 0.35.0 (see screenshot). Policy that’s attached to this role is very permissive (see original post) and contains all actions listed in the screenshot.