Backport/2.18

[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 159 is never consumed if an exception occurs before line 160 enters the try-with-resources block. If getThreadContext().stashContext() throws an exception, the supplier's internal context will not be restored or closed, potentially leaking thread context state. final Supplier<ThreadContext.StoredContext> restorableContextSupplier = getThreadContext().newRestorableContext(true); try (ThreadContext.StoredContext stashedContext = getThreadContext().stashContext()) { Unclosed Resource At line 395, contextToRestore.get() is called but the returned StoredContext is not assigned or closed. This means the context is restored but never explicitly closed, which may leave the thread context in an inconsistent state if the response handler does not complete normally. The old code used restore() which did not require explicit closure. contextToRestore.get();

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	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 [395] -contextToRestore.get(); +try (ThreadContext.StoredContext ignore = contextToRestore.get()) { + // Context is restored here +} Suggestion importance[1-10]: 9 __ Why: The contextToRestore.get() call retrieves a StoredContext but doesn't close it, causing a resource leak. The handleException() method correctly uses try-with-resources, but handleResponse() does not. This is a critical issue that can lead to memory leaks and context corruption.	High