Backport/3.0

[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 161 is never consumed if an exception occurs before line 162. When getThreadContext().stashContext() throws, the supplier holds a context that will never be restored or closed, potentially leaking thread-local state. This occurs whenever stashContext() fails (e.g., due to thread pool shutdown or internal errors). final Supplier<ThreadContext.StoredContext> restorableContextSupplier = getThreadContext().newRestorableContext(true); try (ThreadContext.StoredContext stashedContext = getThreadContext().stashContext()) { Unclosed Resource In handleResponse() at line 401, contextToRestore.get() returns a StoredContext that is never closed. The returned context should be used in a try-with-resources block to ensure proper cleanup. Without closing, thread-local state may leak, especially under high request volumes or when responses are processed on different threads. contextToRestore.get();

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Missing resource cleanup for StoredContext The contextToRestore.get() call in handleResponse() retrieves a StoredContext but doesn't use it in a try-with-resources block, potentially causing a resource leak. The context should be properly closed after restoration to ensure cleanup. src/main/java/org/opensearch/security/transport/SecurityInterceptor.java [401] -contextToRestore.get(); +try (ThreadContext.StoredContext ignore = contextToRestore.get()) { + // Context is restored and will be automatically closed +} Suggestion importance[1-10]: 10 __ Why: The contextToRestore.get() call retrieves a StoredContext without proper resource management, causing a critical resource leak. The handleException() method correctly uses try-with-resources, but handleResponse() does not, leading to inconsistent behavior and potential memory leaks.	High