Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-account pipeline doesn't generate sufficient permissions to deploy lambda in another account #3765

Closed
kamarouski opened this issue Aug 22, 2019 · 6 comments · Fixed by #3855
Assignees
Labels
@aws-cdk/aws-codepipeline Related to AWS CodePipeline bug This issue is a bug.

Comments

@kamarouski
Copy link

🐛 Bug Report

What is the problem?

When using cross-account CloudFormation actions within pipeline to deploy Lambda the stack execution fails with the following error:

Your access has been denied by S3, please make sure your request credentials have permission to GetObject for ARTIFACTS_BUCKET_PATH

Error Code: AccessDenied. S3 Error Message: Access Denied (Service: AWSLambdaInternal; Status Code: 403; Error Code: AccessDeniedException;

This happening because account deployment role doesn't have permissions to both artifacts bucket and KMS key used by the pipeline. CDK only generates permissions for pipeline action role.

Reproduction Steps

  1. Create a pipeline that deploys lambda into another account
  2. Set lambda source code being from pipeline artifacts bucket
  3. Deploy generated supporting stack to lambda account
  4. Deploy pipeline stack to pipeline account
  5. Execute the pipeline

Result: Pipeline fails due to insufficient permissions to deploy lambda.

Environment

  • CDK CLI Version: 1.4.0
  • Module Version: 1.4.0
  • OS: OSX Mojave
  • Language: TypeScript
@kamarouski kamarouski added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Aug 22, 2019
@skinny85 skinny85 added @aws-cdk/aws-codepipeline Related to AWS CodePipeline and removed needs-triage This issue or PR still needs to be triaged. labels Aug 22, 2019
@skinny85 skinny85 self-assigned this Aug 22, 2019
@jpeddicord
Copy link

jpeddicord commented Aug 26, 2019

(Customer hat on -- I don't work on CDK!)

Can reproduce. The KMS key on the bucket artifact effectively prevents a CloudFormation pipeline action from starting (it can't even create a change set). Disabling KMS on the bucket and the individual object that's trying to be deployed will allow that to continue, but that's obviously not the right solution.

@skinny85
Copy link
Contributor

skinny85 commented Aug 26, 2019

Thanks @jpeddicord . The solution here is to add permissions to the deployment Role, not to disable encryption:

myPipeline.artifactBucket.grantRead(myCloudFormationAction.deploymentRole);

(this will include both the Bucket and the Key)

Thanks,
Adam

@jpeddicord
Copy link

@skinny85 Thanks; that makes sense, and adding that did indeed attach some additional permissions to my bucket policy and key. However, I'm not sure that's it (or that it's all of the problem); even after applying that I still observe 403s at action time.

Here's something probably relevant: the S3 bucket that the CDK configures for artifacts has the correct default encryption key. But when CodeBuild writes output objects to that bucket, they don't use the CDK's CMK. They use the "generic" AWS-managed aws/s3 key on the account. That I think might be what's ultimately preventing consuming stacks from accessing the artifacts. I'll tinker and see if I can get that to use the correct key.

@skinny85
Copy link
Contributor

Yes, that is a separate problem :). A workaround can be to set the Project key to be the same as the Pipeline's Key:

new codebuild.PipelineProject(this, 'Project', {
  // ...
  encryptionKey: myPipeline.artifactBucket.encryptionKey,
});

That should make it work.

@jpeddicord
Copy link

Awesome, there it is. Thanks for your help. Both of these things feel like things the CDK should implicitly do; cross-account or not. But I don't think I have the full picture of how that should work. Would these be considered bugs in the CDK, or user/documentation?

@skinny85
Copy link
Contributor

skinny85 commented Aug 26, 2019

The first one is a miss in the CDK (hence this issue 😊). The second... the jury's still out on that one :).

skinny85 added a commit to skinny85/aws-cdk that referenced this issue Aug 29, 2019
…issions

The deploymentRole used in the CloudFormation deployment CodePipeline actions
was not granted explicit permissions to read from the pipeline's bucket.
This meant the deployment failed in the cross-account case
for templates that needed deploy-time access to the bucket
(for example: templates including a Lambda function),
as the pipeline bucket did not trust the deployment role.

Fixes aws#3765
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Aug 29, 2019
…issions

The deploymentRole used in the CloudFormation deployment CodePipeline actions
was not granted explicit permissions to read from the pipeline's bucket.
This meant the deployment failed in the cross-account case
for templates that needed deploy-time access to the bucket
(for example: templates including a Lambda function),
as the pipeline bucket did not trust the deployment role.

Fixes aws#3765
skinny85 added a commit that referenced this issue Aug 29, 2019
…issions (#3855)

The deploymentRole used in the CloudFormation deployment CodePipeline actions
was not granted explicit permissions to read from the pipeline's bucket.
This meant the deployment failed in the cross-account case
for templates that needed deploy-time access to the bucket
(for example: templates including a Lambda function),
as the pipeline bucket did not trust the deployment role.

Fixes #3765
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-codepipeline Related to AWS CodePipeline bug This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants