(codepipeline-actions): BitBucketSourceAction requires s3:PutObjectAcl permissions

[akuma12]

Some time between aws-cdk 1.90.0 and 1.91.0, a bunch of s3:PutObject* permissions were changed to s3:PutObject, but that seems to have caused an issue with the codepipeline-actions.BitBucketSourceAction, leading to the error [GitHub] Upload to S3 failed with the following error: Access Denied in the Source action of a pipeline.

We're using this with GitHub as advised in #10632.

Reproduction Steps

Create a CodePipeline with the BitBucketSourceAction and a codestar-connection to a GitHub repository.

What did you expect to happen?

The source action has the necessary permissions to write to the pipeline artifact bucket.

What actually happened?

The source action failed with the error [GitHub] Upload to S3 failed with the following error: Access Denied

Environment

• CDK CLI Version : 1.92.0
• Framework Version: 1.92.0
• Node.js Version: 14.11.0
• OS : Mac OS Catalina
• Language (Version): Python (3.8.5)

Other

We just need to add s3:PutObjectAcl as part of the default role that is generated for a BitBucketSourceAction.

---

This is 🐛 Bug Report

[skinny85]

Hi @akuma12 ,

that permission was actually changed in release 1.85.0, so it shouldn't be a problem when migrating from 1.90.0 to 1.92.0.

Can you check whether going back to 1.90.0 fixes the issue? What is the output of cdk diff for the Pipeline Stack between those 2 versions?

Thanks,
Adam

[akuma12]

I wasn't sure which change modified the role permissions, but I saw a bunch of removals of s3:PutObject* when comparing 1.90.0 and 1.91.0, so I had assumed that's where it happened. What's crazy is that we've never run into this issue before now, and we've been on at least 1.88.0 for quite a while because of the newStyleStackSynthesis update. I'm not certain what brought this on now.

[Kruspe]

We are facing the same issue and at the moment we are using this workaround #12391 (comment)
Recreating the bucket did not solve the problem for us.

[akuma12]

I guess it would have helped if I'd read the instructions:
Before CDK version 1.85.0, this method granted the s3:PutObject* permission that included s3:PutObjectAcl, which could be used to grant read/write object access to IAM principals in other accounts. If you want to get rid of that behavior, update your CDK version to 1.85.0 or later, and make sure the @aws-cdk/aws-s3:grantWriteWithoutAcl feature flag is set to true in the context key of your cdk.json file. If you've already updated, but still need the principal to have permissions to modify the ACLs, use the {@link grantPutAcl} method.

It looks like cdk init is putting "@aws-cdk/aws-s3:grantWriteWithoutAcl": "true" in the cdk.json file by default, which is what caused the issue. I set it to "false" and it put the s3:PutObject* permission back in the policy. I imagine this was an unintended side-effect, but I wonder if anything can be done with the BitBucketSourceAction construct to add s3:PutObjectAcl to the policy so others don't have to bang their heads against a desk ;)