feat(opensearch): update default TLS security policy to TLS 1.2 for OpenSearch domains

[pahud]

Description

This PR fixes the issue where OpenSearch domains were not getting a default TLS security policy, causing inconsistent behavior between the CDK construct and the actual AWS service default.

Previous behavior:

• CDK construct: No tlsSecurityPolicy specified → TLSSecurityPolicy.TLS_1_0
• AWS service: Defaults to TLS 1.2 when TLSSecurityPolicy is not specified in CloudFormation

New behavior:

• CDK construct: No tlsSecurityPolicy specified → CDK explicitly sets TLSSecurityPolicy: Policy-Min-TLS-1-2-2019-07
• Result: Consistent TLS 1.2 behavior between CDK construct and AWS service

Changes Made

1. Updated domain.ts: Modified the DomainEndpointOptions configuration to use TLSSecurityPolicy.TLS_1_2 as the default when props.tlsSecurityPolicy is undefined:

  tlsSecurityPolicy: props.tlsSecurityPolicy ?? TLSSecurityPolicy.TLS_1_2,

3. Added comprehensive tests: Created a new test suite covering:
   - Default TLS 1.2 behavior when no policy is specified
   - Explicit TLS policy values (1.0, 1.2, 1.2 PFS)
   - Interaction with enforceHttps setting
   - Backward compatibility scenarios
4. Add a new integ test that checks DomainEndpointOptions to include the expected TLSSecurityPolicy assertion, ensuring they reflect the new default behavior.

Approach Rationale

This approach is simpler and more predictable:

• CDK-controlled defaults: We simply change the implicit default from TLS 1.0 to TLS 1.2, ensuring the default value is fully controlled by CDK even when undefined
• Breaking change: This changes the default TLS security policy behavior and should be called out in release notes
• Matches integration test expectations: Aligns with existing integration test assertions that expect TLSSecurityPolicy: Policy-Min-TLS-1-2-2019-07
• Follows AWS best practices: TLS 1.2 is the recommended minimum security standard

Testing

• ✅ All existing OpenSearch domain tests pass (1,616 tests)
• ✅ New comprehensive TLS security policy test suite
• ✅ Integration test integ.opensearch.https.ts continues to pass
• ✅ No linting issues

Related Issues

Closes #34658

Breaking Changes

OpenSearch Domain TLS Security Policy Default Changed

• The default TLS security policy for OpenSearch domains has changed from TLS 1.0 to TLS 1.2
• Impact: Domains created without an explicit tlsSecurityPolicy will now use TLS 1.2 instead of TLS 1.0
• Migration: If you require TLS 1.0 for backward compatibility, explicitly set tlsSecurityPolicy: TLSSecurityPolicy.TLS_1_0

---

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

[pahud]

updating integ tests snapshots

[aws-cdk-automation]

(This review is outdated)

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

[vishaalmehrishi]

Is there a risk of breaking existing customers who intentionally did not provide a security policy with the assumption that it would use Policy-Min-TLS-1-0-2019-07? This change will implicitly update the TLS security policy (by using the OpenSearch default) without customers knowing, which could break their existing setups which rely on the specific version.

[pahud]

Yes it will. To avoid this, I guess the only option for us is to introduce a new FF. Should we do that?

[vishaalmehrishi]

I see the update in the User Impact section (and the testing done as well - thank you!):

Existing users with tlsSecurityPolicy undefined won't be impact, changing tlsSecurityPolicy from a cdk defined TLS 1.0 to undefined won't update the existing deployment. See Description of how you validated changes below.
After this PR, for all new deployments, the default will be TLS 1.2 if undefined. Users have to explicitly opt in TLSSecurityPolicy.TLS_1_0 if they need to stick to this version.

Do you think there is value in publishing a notice/informing customers somehow about this change? It seems safe to me, based on your testing, but it is possible that we are not thinking about a particular customer setup which can break.

[vishaalmehrishi]

Comment on the commit message:

fix(opensearchservice): aws-opensearchservice: remove default TLS policy

Might be better to say:

fix(opensearchservice): aws-opensearchservice: use OpenSearch default TLS policy instead of CDK-specified default TLS policy

[mrgrain]

chore(opensearchservice): use OpenSearch default TLS policy instead of CDK-specified default TLS policy

Definitely not a chore either. Only changes that have no bearing on our customers should chores. Changing the default is always going to be something customer facing.

fix: describe the bug (not the solution)

Yes, but just because the issue has a certain title doesn't mean that title should be used. The bug isn't really "remove default TLS policy" but would be something like "cannot use OpenSearch default TLS policy because of outdated CDK-specified default TLS policy"

IMO this is not a bug. The current code falls back to an older TLS version, but that was intended behaviour which now needs updating, which is different from a bug (unintended behaviour).

FWIW I'd probably classify it as a feature.

[aws-cdk-automation]

(This review is outdated)

[pahud]

Exemption Request for the README update

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

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.