feat(rds): default DatabaseCluser and DatabaseInstance storageEncrypted to true (under feature flag)

[blimmer]

Issue # (if applicable)

Closes #32398

Reason for this change

Today, if you don't remember to pass storageEncrypted: true to your DatabaseInstance or DatabaseCluster, your database's storage will be unencrypted.

In almost all cases, your database storage should be encrypted. Here are reasons I think we should use AWS-managed keys by default:

• AWS Well-Architected security pillar says all data should be encrypted at rest.
• There is no additional fee to use the AWS-managed KMS key
• When creating RDS instances and clusters via the AWS Console UI, encryption with AWS-managed keys is enabled by default.
• Adding encryption to a previously unencrypted database is an involved process that requires recreating your database from a snapshot. Applying encryption to an unencrypted database is time-consuming and a bad developer and user experience.
• Other L2 constructs apply encryption by default, including Neptune and DocDb
• If you don't encrypt your storage, you'll see warnings in the RDS UI telling you that your storage is unencrypted.
• Users can easily retain the existing behavior.

Description of changes

This PR introduces a new feature flag, @aws-cdk/aws-rds:enableEncryptionAtRestByDefault. When set to true, storageEncrypted will default to true instead of undefined (which means "false").

To provide backward compatibility, this PR also introduces a new property, isStorageLegacyUnencrypted. This allows leaving the StorageEncrypted property unset in the CloudFormation template, to avoid replacing Database instances/clusters.

Describe any new or updated permissions being added

N/A

Description of how you validated changes

Unit and integration tests.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[blimmer]

This change affected a lot of integration tests. I opted to use the legacy behaviors for these tests because re-running the creation of all these databases would be extremely slow and expensive.

If someone at AWS with a "free"/"expensed" account would like to rerun all these failing tests, we could go that route, too.

I added explicit new tests for this behavior.

[lpizzinidev]

I think manually adding "StorageEncrypted": true to the templates would make those tests pass without the need to deploy the related resources (we expect the flag to work given that you added the new test).

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.96%. Comparing base (fcf4ecd) to head (4497f62).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #32695   +/-   ##
=======================================
  Coverage   66.95%   66.96%           
=======================================
  Files         329      329           
  Lines       18662    18663    +1     
  Branches     3257     3257           
=======================================
+ Hits        12496    12497    +1     
  Misses       5839     5839           
  Partials      327      327           

Flag	Coverage Δ
suite.unit	66.96% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	80.71% <ø> (ø)
packages/aws-cdk-lib/core	82.08% <ø> (ø)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 4497f62
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[lpizzinidev]

To provide backward compatibility, this PR also introduces a new property, isStorageLegacyUnencrypted. This allows leaving the StorageEncrypted property unset in the CloudFormation template, to avoid replacing Database instances/clusters.

Shouldn't the default behavior be applied when @aws-cdk/aws-rds:enableEncryptionAtRestByDefault: false? 🤔
The extra variable seems to add unnecessary complexity here.

[lpizzinidev]

I think manually adding "StorageEncrypted": true to the templates would make those tests pass without the need to deploy the related resources (we expect the flag to work given that you added the new test).