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, storageEncryptedLegacyDefaultValue. 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).

[blimmer]

In the past, I've received PR feedback that you should never manually update snapshot files. I just confirmed that I could add this property manually to the snapshots and that would be an alternative solution to updating the stack definitions.

I'd like a +1 from an approver that this would be OK before I spend the time doing it, based on previous feedback that snapshots should never be manually edited.

[lpizzinidev]

I've received PR feedback that you should never manually update snapshot files

👍 Sounds good!

About the isStorageLegacyUnencrypted comment.
Thanks for clarifying, I'm not sure why CFN defaults to unencrypted clusters and instances.
However, I left some comments on the implementation for small adjustments.

[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 81.52%. Comparing base (bbdd42c) to head (14795d0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #32695   +/-   ##
=======================================
  Coverage   81.52%   81.52%           
=======================================
  Files         222      222           
  Lines       13715    13715           
  Branches     2417     2417           
=======================================
  Hits        11181    11181           
  Misses       2254     2254           
  Partials      280      280           

Flag	Coverage Δ
suite.unit	81.52% <ø> (ø)

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

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

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

[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).

[blimmer]

@lpizzinidev - thanks for the review. I commented on your inline comment, and below is a comment that you requested changed for (it's annoying that GitHub won't let you respond inline to those).

Suggestion to reuse feature flag vs isStorageLegacyUnencrypted

This would work for v2, but if the feature flag is ever removed (it looks like all v1 flags were removed from v2 - see docs), this would no longer work. My understanding is that when v3 is released, the feature flag will be removed, and we will need to remember to re-add something like isStorageLegacyUnencrypted.

This is very similar to the isFromLegacyInstanceProps provided for a similar reason, to prevent replacing database resources (docs).

Unfortunately, because the behavior is to pass undefined today, it makes it a bit challenging to work with. CloudFormation reports that changing undefined -> false causes resource replacement. I feel fairly strongly that the new behavior should be to always explicitly set the value to true or false, which led me to this solution.

If there's another way I should be thinking about this (like retaining that feature flag indefinitely - I don't know if that's an option), let me know.

[lpizzinidev]

I've received PR feedback that you should never manually update snapshot files

👍 Sounds good!

About the isStorageLegacyUnencrypted comment.
Thanks for clarifying, I'm not sure why CFN defaults to unencrypted clusters and instances.
However, I left some comments on the implementation for small adjustments.

[blimmer]

@lpizzinidev - thanks for the thorough review and great comments. This is ready for re-review.

[lpizzinidev]

Thanks 🚀 Left comments for some final adjustments

[blimmer]

@lpizzinidev - thanks! should be good to go.

[lpizzinidev]

Thanks 👍

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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