Disable moto S3 bucket policy enforcement to unblock CDK bootstraps#7907
Disable moto S3 bucket policy enforcement to unblock CDK bootstraps#7907
Conversation
|
definitely think this is a bit too restrictive on moto's side. @whummer i saw that @viren-nadkarni reverted this commit in moto-ext: localstack/moto@ffca152 how do we plan to consolidate the changes in this PR and the commit revert? can we remove the reverted commit and just use the patch? is there some dependence between the two? |
|
@thrau Good catch, thanks! (looks like I didn't have that moto change locally yet 🙈 ). To me, either way is fine - undoing the commit revert maybe could make sense (to reduce the number of potential rebase conflicts, going forward). 👍 In any case, this PR would only work/build if the commit revert is undone (otherwise it could also be closed.. 🤷 ). Thoughts @viren-nadkarni ? |
|
Before doing a review I'll wait for the decision between the revert of the commit or patching, but I have opinions on the patching. To make a clear difference between the legacy and the new ASF provider, patches have been duplicated. The best would be to add this patch both in |
|
Viren and I decided to revert the patch for now, as it would have unforseen consequences and does not integrate with our IAM enforcement at all. |
|
I think this patch makes sense over maintaining the revert commit in moto-ext. There were already quite a few conflicts during the last moto-ext bump (4.1.4). I will re-release moto-ext with latest 4.1.5 changes and remove the revert commit. We can merge this PR after the bump 👍 |
With getmoto/moto#6049, policies are saved as str
|
moto-ext is now bumped to 4.1.5.post1 |
whummer
left a comment
There was a problem hiding this comment.
LGTM ✅ Thanks @viren-nadkarni for pushing this one over the line! 🙌
|
LGTM too for the code I haven't written 😄 that's one collaborative PR! |
Disable moto's S3 bucket policy enforcement to unblock CDK bootstraps and bump moto-ext to
4.1.5.post1Moto recently added more strict bucket policy enforcement: getmoto/moto#5883
This can break
cdklocal bootstrapcommands, as CDK is creating a bucket policy that denies access to bucket objects over non-SSL connections (by enforcing theaws:SecureTransportattribute in the policy): https://github.com/aws/aws-cdk/blob/e8158af34eb6402c79edbc171746fb5501775c68/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L217-L233After the bootstrap,
cdklocal deploycan then result in errors in the CloudFormation deployment:This was discovered when deploying some CDK stacks recently, among others this Developer Hub sample here: localstack-samples/sample-microservices-apigateway-lambda-dynamodb-sqs#1
Seems like a reasonable approach to disable the bucket enforcement entirely (without making it configurable), to unblock CDK users, and also given the recent enhancements in our own IAM enforcement - but open to suggestions! /cc @bentsku @dfangl @thrau