Setup extension TLS

[cwperks]

Description

Companion PR in core: opensearch-project/OpenSearch#6866
Companion PR in security repo: opensearch-project/security#2599

I am opening a draft PR to solicit feedback for setting up extension TLS. The TLS setup here is modeled after the setup in security plugin, but any reference to http setup was removed and all transport setup kept in. While testing extensions with the Security plugin installed, I ran into issues where the extension was not able to handshake with the cluster as it was hitting this block: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/transport/SecurityRequestHandler.java#L260-L268

//this is a netty request from a non-server node (maybe also be internal: or a shard request)
//and therefore issued by a transport client

//since OS 2.0 we do not support this any longer because transport client no longer available

final OpenSearchException exception = ExceptionUtils.createTransportClientNoLongerSupportedException();
log.error(exception.toString());
transportChannel.sendResponse(exception);
return;

This PR updates the handshake process and injects a ThreadContext header (extension_unique_id) that is added on all transport requests to core, to identify the transport request as explicitly coming from an extension.

For the TLS setup in this PR, I have added a general area in the extension settings (i.e. helloworld-settings.yml) where the TLS can be configured using any of the ConfigConstants present in SSLConfigConstants. All settings for SSL setup are prefixes with ssl.transport.* and SSL must be explicitly enabled with default to false (though I imagine this will change in a future PR as the security changes are closer to being finalized for the experimental release).

See a snippet from helloworld-settings.yml with SSL config:

ssl.transport.enabled: true
ssl.transport.pemcert_filepath: certs/extension-01.pem
ssl.transport.pemkey_filepath: certs/extension-01-key.pem
ssl.transport.pemtrustedcas_filepath: certs/root-ca.pem
ssl.transport.enforce_hostname_verification: false
path.home: /Users/cwperx/Projects/opensearch/opensearch-sdk-java // Looks for config/ folder under this path when looking for certs

I added commands in Docs/CERTIFICATE_GENERATION.md that you can use to generate certs for the extension and for the OS node to test with.

I was not sure how to add automated testing for this - I will open up an issue for adding tests

Issues Resolved

opensearch-project/security#2638

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[saratvemulapalli]

Merged companion PR on OpenSearch, gradle check should pass.

[cwperks]

@saratvemulapalli The gradle check passed now that the companion PR in core has been merged. Thank you!

[saratvemulapalli]

@opensearch-project/opensearch-sdk-java looking for another set of eyes.

[cwperks]

I will create an issue to move the classes in org.opensearch.sdk.ssl to a library somewhere that both the security plugin and the sdk can depend on and import.

[peternied]

I've left a number of comments that I think all bubble up to the notion of having a shared library for SSL. Great job getting this working end to end.

[cwperks]

I created 2 follow-up issues around TLS to create integration tests and extract the common code with the security plugin into a library:

• Move the classes in org.opensearch.sdk.ssl to a library that the SDK can depend on  #714
• Create integration tests to verify the extension TLS behavior #715

[owaiskazi19]

Overall LGTM! Sorry for the delay. A quick question though. What if in the future we plan to move the security plugin to core, how will we handle the files/changes that we pulled in this PR directly from security plugin?

[cwperks]

@owaiskazi19 In either case with security as a plugin or security in core we would extract the same files that help setup TLS to a library that both can depend on.

[saratvemulapalli]

Thanks @cwperks for these changes!!
Getting this working E2E is great!

[owaiskazi19]

LGTM! Thanks @cwperks for addressing the comments. Can the reviewers resolve the comments if changes looks good and we can get this in?

[cwperks]

@owaiskazi19 I went through each comment marked unresolved and marked them each as resolved. There were a few items from Peter, namely around the placement of the path.home setting, that I plan to address in a future PR. I have opened up 2 issues around integration tests for this change and extracting common files to a library.

[vibrantvarun]

Great work, @cwperks Thanks

[opensearch-trigger-bot]

The backport to 1.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-1.x 1.x
# Navigate to the new working tree
pushd ../.worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-619-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 b13f257dac430d24404105ae69f31e334ba84df2
# Push it to GitHub
git push --set-upstream origin backport/backport-619-to-1.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-1.x

Then, create a pull request where the base branch is 1.x and the compare/head branch is backport/backport-619-to-1.x.

[owaiskazi19]

@owaiskazi19 I went through each comment marked unresolved and marked them each as resolved.

Thanks. Generally, we prefer the reviewer to resolve the comments if the changes requested looks good to them.
Also, can you raise a manual backport PR to 1.x since the workflow failed?

[cwperks]

Yes I will raise a manual PR for the 1.x backport. Understood about letting reviewers mark the PR as resolved, this PR was sitting for a while and I was trying to move it forward and use discretion with whether a comment was addressed. This should be the largest PR in size for a while since it added a lot of configurability around TLS, but future security related PRs will be much smaller comparatively.

[cwperks]

@owaiskazi19 Opened up a manual backport PR: #718