Backport/2.15

[KishoreKicha14]

Description

[Describe what this change achieves]

• Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
• Why these changes are required?
• What is the old behavior before changes and new behavior after changes?

Issues Resolved

[List any issues this PR will resolve]

Is this a backport? If so, please add backport PR # and/or commits #, and remove backport-failed label from the original PR.

Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here

Testing

[Please provide details of testing done: unit testing, integration testing and manual testing]

Check List

• New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• Commits are signed per the DCO using --signoff

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.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Resource Leak The restorableContextSupplier created at line 158 is never closed or consumed in the exception path. If stashedContext.stashContext() throws before line 160-163 executes, the supplier's internal context remains unreleased. This can leak thread-local state if exceptions occur during context stashing. final Supplier<ThreadContext.StoredContext> restorableContextSupplier = getThreadContext().newRestorableContext(true); try (ThreadContext.StoredContext stashedContext = getThreadContext().stashContext()) { final TransportResponseHandler<T> restoringHandler = new RestoringTransportResponseHandler<T>( handler, restorableContextSupplier ); Unclosed Context At line 385, contextToRestore.get() returns a StoredContext that is never closed. The returned context should be used in a try-with-resources block or explicitly closed to prevent thread-local leaks. The old code called .restore() which handled cleanup; the new code retrieves but does not close the context. contextToRestore.get();

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix resource leak in context restoration The contextToRestore.get() call in handleResponse() retrieves a new StoredContext but doesn't restore it or close it, causing a resource leak. The retrieved context should be used in a try-with-resources block to ensure proper restoration and cleanup. src/main/java/org/opensearch/security/transport/SecurityInterceptor.java [385] -contextToRestore.get(); +try (ThreadContext.StoredContext ignore = contextToRestore.get()) { + // Context is automatically restored and closed +} Suggestion importance[1-10]: 10 __ Why: The contextToRestore.get() call retrieves a StoredContext without closing it, causing a critical resource leak. The improved code correctly uses try-with-resources to ensure proper cleanup, which is essential for preventing memory leaks in production.	High
	Capture context state after stashing The restorableContextSupplier is created before stashing the context, which may capture the wrong context state. The restorable context should be created after the context is stashed to ensure it captures the correct state for restoration. src/main/java/org/opensearch/security/transport/SecurityInterceptor.java [158-163] -final Supplier<ThreadContext.StoredContext> restorableContextSupplier = getThreadContext().newRestorableContext(true); try (ThreadContext.StoredContext stashedContext = getThreadContext().stashContext()) { + final Supplier<ThreadContext.StoredContext> restorableContextSupplier = getThreadContext().newRestorableContext(true); final TransportResponseHandler<T> restoringHandler = new RestoringTransportResponseHandler<T>( handler, restorableContextSupplier ); Suggestion importance[1-10]: 9 __ Why: Creating restorableContextSupplier before stashing the context captures the wrong state. The context should be captured after stashing to ensure the correct state is restored later, which is critical for maintaining proper thread context isolation in distributed requests.	High