You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
S3 Object Lock allows configuring various retention holds, for legal and compliance purposes, on an S3 bucket. This enables a write-once-read-many model. Object Lock can only be enabled on new buckets via the CloudFormation (and therefore via the CDK). Updates to an existing bucket will result in a CloudFormation update failure.
This behavior is possible today using Escape Hatches to modify the L1 construct (with the same limitations):
```ts
cfnBucket.addPropertyOverride("ObjectLockEnabled", true);
```
Providing L2 wrappers around this configuration can aleviate some common and easy-to-make mistakes, such as providing `ObjectLockConfiguration` without providing `ObjectLockEnabled` or specifying `"Governance"` instead of `"GOVERNANCE"` for the compliance mode.
It is possible to enable Object Lock without specifying a default duration. Therefore, there needs to be a means to set `ObjectLockEnabled`. This is done with the `ObjectLoc.enabled` property. Since this is a boolean, it can theoretically be set to `false`. If `false` and a `defaultRetention` is provided, an error is thrown.
CloudFormation allows specifying `Days` or `Years` for retention; for simplicity, this implementation always converts to `Days`. Because CloudFormation requires that to be a positive integer, this implementation also proactively performs that validation at synthesis time.
Further, CloudFormation does not allow omitting `ObjectLockEnabled` within `ObjectLockConfiguration`. The following template would result in a validation error that the input does not match the schema:
```yaml
Bucket:
Type: AWS::S3::Bucket
Properties:
ObjectLockEnabled: true
ObjectLockConfiguration:
Rule:
DefaultRetention:
Days: 1
Mode: GOVERNANCE
```
Therefore, this implementation also always sets
`ObjectLockConfiguration.ObjectLockEnabled` to `"Enabled"`.
Additionally, it seems that the behavior of doing
```yaml
Bucket:
Type: AWS::S3::Bucket
Properties:
ObjectLockEnabled: true
ObjectLockConfiguration:
ObjectLockEnabled: 'Enabled'
```
causes CloudFormation to create the buckets with Object Lock enabled and then just wait and wait and wait. Frankly I didn't wait for the operation to time out so I don't know whether that would succeed or fail, but in any case, that would be a duplicate of specifying only `ObjectLockEnabled: true` (without nested in `ObjectLockConfiguration`) so this implementation prefers the shorter variant, which CloudFormation/S3 also seem to prefer, when Object Lock is enabled without default retention.
Unfortunately, there isn't a way to check during synthesis whether the bucket already exists, so there's not really a way to detect that pitfall. Users will just get the typical CloudFormation error for this situation and a stack rollback.
More variants of Object Lock configuration in S3 and descriptions of what CloudFormation does with them can be found at: https://gist.github.com/788df029f121af14645f31152ff54e32
This _partially_ addresses #5247 (nothing here handles MFA delete).
This follows up on #21738 which has been marked as abandoned.
----
### All Submissions:
* [X] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)
### Adding new Construct Runtime Dependencies:
* [ ] This PR adds new construct runtime dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies)
### New Features
* [X] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
* [X] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
0 commit comments