Set gRPC security interceptor to highest priority

[aparajita31pandey]

Description

Prioritize security gRPC interceptor with minimum order value

• Conceptually gRPCInterceptor follows similar pattern like ActionFilter
• SecurityFilter which implements ActionFilter in opensearchSecurity has ordering on Integer.MIN_VALUE -https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/filter/SecurityFilter.java#L173 following similar in SecurityGrpcFilter

Issues Resolved

[#5812]

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]
Unit Test Added

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.

[cwperks]

@aparajita31pandey Can we add a CHANGELOG entry for this?

[aparajita31pandey]

Thankyou @cwperks for quick review. Added CHANGELOG entry for this change

[nibix]

it seems that we have integration test failures

2026-02-04T07:46:10.6555519Z 
2026-02-04T07:46:10.6555655Z > Task :integrationTest
2026-02-04T07:46:10.6555883Z 
2026-02-04T07:46:10.6556258Z JWTGrpcInterceptorTest > testUserInjectionWithNoAuthUser FAILED
2026-02-04T07:46:10.6557159Z     io.grpc.StatusRuntimeException: UNAUTHENTICATED: Authentication finally failed
2026-02-04T07:46:10.6558262Z         at app//io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:368)
2026-02-04T07:46:10.6559181Z         at app//io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:349)
2026-02-04T07:46:10.6560013Z         at app//io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:174)
2026-02-04T07:46:10.6561351Z         at app//org.opensearch.protobufs.services.DocumentServiceGrpc$DocumentServiceBlockingStub.bulk(DocumentServiceGrpc.java:160)
2026-02-04T07:46:10.6562701Z         at app//org.opensearch.security.grpc.GrpcHelpers.doBulk(GrpcHelpers.java:278)
2026-02-04T07:46:10.6564302Z         at app//org.opensearch.security.grpc.JWTGrpcInterceptorTest.testUserInjectionWithNoAuthUser(JWTGrpcInterceptorTest.java:390)
2026-02-04T07:46:10.7503772Z 
2026-02-04T07:46:10.7504584Z JWTGrpcInterceptorTest > testLimitedUserInjectionWithValidAuthUser FAILED
2026-02-04T07:46:10.7505366Z     java.lang.AssertionError
2026-02-04T07:46:10.7505793Z         at org.junit.Assert.fail(Assert.java:87)
2026-02-04T07:46:10.7506687Z         at org.junit.Assert.assertTrue(Assert.java:42)
2026-02-04T07:46:10.7507219Z         at org.junit.Assert.assertTrue(Assert.java:53)

[finnegancarroll]

It looks like this change is colliding with the TestUserInjectionInterceptorProvider injected into the gRPC transport in the integration test suite.

This class mocks a gRPC interceptor which might perform user injection by reading the "test-user-injection" header and stashing it in the thread context under OPENDISTRO_SECURITY_INJECTED_USER. Since user injection is handled in the AuthNGrpcInterceptor this user injection interceptor has order -1.

Do we necessarily want the AuthNGrpcInterceptor to always execute first in the chain? I'm wondering if we want to reserve space for these user injection use cases, or maybe something like a custom compression/decompression handler which may want to execute before we handle auth.

[nibix]

@finnegancarroll

I cannot really comment on most of the points, as I was not really involved in the architecture. Just a few cents:

I'm wondering if we want to reserve space for these user injection use cases, or maybe something like a custom compression/decompression handler which may want to execute before we handle auth.

For HTTP, it is important to be able to do authn before decompression is applied to avoid unauthenticated DDOS attacks. I do not know so much about gRPC, but that might be a similar consideration there, right?

[finnegancarroll]

For HTTP, it is important to be able to do authn before decompression is applied to avoid unauthenticated DDOS attacks. I do not know so much about gRPC, but that might be a similar consideration there, right?

I think my compression example was not great but maybe some other use cases which would need to execute before security plugin could be:

• Custom rate limiting (Security plugin has limited failed login support)
• Observability use cases where we want information about every request, not just those authenticated
• User injection use cases where we authenticate a user with a proprietary/unsupported auth backend and want to take advantage of security plugin FGAC.

By making the gRPC filter max prio we remove the above use cases. Is the idea to protect future plugin developers from accidentally registering an insecure intercepter or doing unnecessary work ahead of the grpc security filter?