s3: feature flag to make AWS's new blockPublicAccess and ownershipControls defaults explicit

[plumdog]

Describe the feature

A feature flag that removes reliance on Cloudformation defaults for blockPublicAccess and ownershipControls (or objectOwnership as BucketProps calls it) and instead sets them explicitly in the generated Cloudformation.

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.Bucket.html#blockpublicaccess says:

default: CloudFormation defaults will apply. New buckets and objects don't allow public access, but users can modify bucket policies or object permissions to allow public access

Which I think is a usability bug, and I think "users can modify bucket policies or object permissions to allow public access" might be false as of 27th April 2023.

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.Bucket.html#objectownership say:

default: No ObjectOwnership configuration, uploading account will own the object.

Which I think might actually be false as of 27th April 2023.

Use Case

In the light of https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/, we have a problem where the birthdate of a bucket affects how they behave unless that behaviour is set explicitly.

So we have CDK projects where the same code deployed two essentially identical stacks, but either side of the behaviour change date. A diff or update to the older stack finds no changes. But I don't want this variance, I want two CDK stacks that are the same - up to naming - behave the same.

Proposed Solution

A CDK feature flag so that there is some consistent default behaviour explicitly applied to all s3.Bucket resources.

This should almost certainly match S3's new defaults, so should set:

blockPublicAccess.BlockPublicAccess.BLOCK_ALL,
objectOwnership: s3.ObjectOwnership.BUCKET_OWNER_ENFORCED,

In other words:

new s3.Bucket(this, 'MyBucket');

would produce an L1 like

new s3.CfnBucket(this, 'MyBucket', {
    // ...
    publicAccessBlockConfiguration: {
        blockPublicAcls: true,
        blockPublicPolicy: true,
        ignorePublicAcls: true,
        restrictPublicBuckets: true,
    },
    ownershipControls: {
        rules: [{
            objectOwnership: 'BucketOwnerEnforced',
        }],
    },
});

Enabling this feature flag would mean ensure that all buckets managed by the CDK would have consistent behaviour regardless of creation date.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2

Environment details (OS name and version, etc.)

n/a

[peterwoodworth]

Thank you for reporting this, our docstrings are incorrect and need to be updated.

Regarding the feature flag suggestion - I can't figure out exactly what value it provides. To me it seems the feature flag would only explicitly declare this for people who are creating new stacks past the date of changes. People who have already created CDK apps before the date will need to manually add this flag to their app, and if they do this it would cause all buckets to automatically change behavior if no settings are specified, which may be undesired for some buckets.

[paulhcsun]

Hi @plumdog, could you clarify what you mean by the docstrings are incorrect? According to the to links attached to the properties, the current docstrings are up to date with the new defaults being in place for Block Public Access being enabled and ACLs disabled:

• blockPublicAccess: "...However, users can modify bucket policies, access point policies, or object permissions to allow public access..."
• objectOwnership: "...Bucket owner enforced (default) – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket..."

I also agree that a feature flag is not the right fix here. It could be possible to create a tool in cdklabs that can be used to update existing buckets but without changing the code in a users stack it's possible that the old settings will just override the changes when the stack is deployed again.

I'll close this for now as we won't be accepting a feature flag for this fix and if we do create a tool it would not live in aws-cdk, and also the current docuentation appears to be correct and aligns with S3's documentation. Feel free to reopen if you feel the docstrings are indeed incorrect and need to be changed.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.