Generated permissions insufficient to deploy to Lambda

[lennartcl]

When I try to deploy to Lambda from a pipeline with a CloudFormationCreateUpdateStackAction action, the deployment fails due to insufficient permissions.

Reproduction Steps

1. Follow https://docs.aws.amazon.com/cdk/latest/guide/codepipeline_example.html
2. Pipeline will fail

• Error shown is "UPDATE_FAILED Your access has been denied by S3, please make sure your request credentials have permission to GetObject for [...]. S3 Error Code: AccessDenied. S3 Error Message: Access Denied (Service: AWSLambdaInternal; Status Code: 403; Error Code: AccessDeniedException; [...])"
• Further inspection reveals that the KMS key used with the source code bucket doesn't whitelist the execution role for the Lambda function.

Workaround

Using the following class instead of CloudFormationCreateUpdateStackAction will grant the required permissions:

class FixedStackAction extends codepipeline_actions.CloudFormationCreateUpdateStackAction {
  bound(scope: any, stage: any, options: any): any {
    const result = super.bound(scope, stage, options);
    options.bucket.grantRead((this as any)._deploymentRole);
    return result;
  }
}

Suggested fix

Review adding grantRead() to CloudFormationCreateUpdateStackAction as appropriate.

[skinny85]

Hey @lennartcl ,

thanks for opening the issue. What version of the CDK you got this problem with?

Thanks,
Adam

[lennartcl]

@skinny85 I've seen this with versions 16.1 through 17.1. Haven't tried with older versions.

[skinny85]

Can you show the CloudFormationCreateUpdateStackAction code that is causing this error during deployment?

[lennartcl]

The issue seems to be that grantRead() is only called in cross-account scenarios in pipeline-actions.ts#L282-L286. By doing that even when (roleStack.account === pipelineStack.account), we can make sure that the KMS key gets the execution role in its policy.

[skinny85]

You're correct, I've managed to reproduce the problem. I'll be working on a fix.

[greenpau]

I am running into this issue too. I have a pipeline that manages objects via CloudFormation across multiple accounts in AWS Organizations.

When a CloudFormation in subordinate account tries accessing S3 bucket with artifacts, I see the following CloudWatch Log entry.

{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "ARAAZZ5BACO6CCB5XLZAS:1577238726275",
        "accountId": "SUBORDINATE_ACCOUNT_ID",
        "invokedBy": "AWS Internal"
    },
    "eventTime": "2019-12-25T01:52:06Z",
    "eventSource": "s3.amazonaws.com",
    "eventName": "GetObject",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "10.246.100.101",
    "userAgent": "[CloudFormation CodePipeline Action, aws-internal/3 aws-sdk-java/1.11.534 Linux/4.9.184-0.1.ac.235.83.329.metal1.x86_64 OpenJDK_64-Bit_Server_VM/25.202-b08 java/1.8.0_202 vendor/Oracle_Corporation]",
    "errorCode": "AccessDenied",
    "errorMessage": "Access Denied",
    "recipientAccountId": "CODEPIPELINE_ACCOUNT_ID"
}

I had to grant the following S3 bucket permission for cross-account access. I don't like to do it, but that is a solution. Is there another way to permit it? 🤔 I don't like using "Principal": "*" in the statement.

        {
            "Sid": "Allow Access By Anyone in AWS Organization",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::MYBUCKETNAME/*",
                "arn:aws:s3:::MYBUCKETNAME/*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-MYORGID"
                }
            }
        }

[solshark]

I'm trying to deploy stack within same account with adminPermissions: true and also facing same issue.

Version 1.19.0 (build 5597bbe)

[skinny85]

Yep, this fix will be part of version 1.20.0, which should be released this week.

[solshark]

Looking very much forward.

[solshark]

Any news here?

[skinny85]

We have a release happening as we speak, please be patient a little while longer!