peterwoodworth
commented
2 years ago The CDK creates CloudFormation templates - if lookup based on account information is needed to see whether to specify a property or not, it's expected that the user will do that. Also, if using CfnBucket, there's nothing CDK can do because all of our CloudFormation resources (prefixed with Cfn) are automatically generated and are identical to their respective CloudFormation resources. Responsibility for this functionality would go to CloudFormation, and then be automatically supported by us.
On the topic of your deployments failing because of this - that's a CloudFormation issue which CDK has no control over. CloudFormation has a public roadmap where you can submit issues, I recommend reaching out to them about this 🙂
github-actions[bot]
Describe the bug
When using BlockPublicAccess parameter on Bucket or CfnBucket with an account which already has BlockPublicAccess enabled, the deployment of the bucket fails.
I understand that this is intentional and the users are notified this way. However, I argue that this is a deterrent. Often times we deploy buckets with a lifecycle of RETAIN and thus, we need to manually delete the bucket before continuing when we encounter with this error.
We often deploy buckets to multiple accounts with the same pattern for naming conventions to differentiate between accounts. Some of the accounts contain the account wide public block, others do not. Thus in our pipelines, some deployments fail and others do not. We then need to intervene to get the pipeline going.
Using a custom resource is also not a possibility because we have to lookup the account value and create a condition on whether we want BlockPublicAccess on the bucket or not. Conditions are handled on the construct phase and the value of a custom resource is returned on Post synthesis phase.
It would be best if cloudformation/CDK can lookup the value prior to deploying the cloudformation stack. Another possible solution would be for cloudformation/CDK to ignore this parameter on the bucket if the account wide block is enabled. I understand the second option is less desirable but the first should be possible.
Expected Behavior
If CFN/CDK can determine the BlockPublicAccess value prior to deploying buckets before the synthesis phase, that would be best.
Current Behavior
Cloudformation fails if both BlockPublicAccess ACL is provided already on the account and is also provided on the bucket to be deployed
Reproduction Steps
Enable BlockPublicAccess ACL on the account on S3 resource. Deploy a bucket with BlockPublicAccess ACL.
Possible Solution
CFN/CDK to determine what the current account value is prior synthesis phase.
Additional Information/Context
No response
CDK CLI Version
2.20
Framework Version
No response
Node.js Version
16.13
OS
macos
Language
Typescript
Language Version
No response
Other information
No response