[Question] Can NetworkPlugin.getHttpTransports be limited to a single plugin

[cwperks]

Related to: opensearch-project/OpenSearch#10260

As part of the work to move authentication up the netty pipeline before decompression, the security plugin would be adding a new step in the netty pipeline called header_verifier which would be added as part of the NetworkPlugin.getHttpTransports extension point instead of the ActionPlugin.getRestHandlerWrapper extension point.

The ActionPlugin extension point has restrictions where only a single plugin can provide an implementation. If multiple plugins installed try to implement the same interface, the node will fail to start and provide a message that only a single plugin can provide an implementation.

If authn is moved into NetworkPlugin.getHttpTransports(), can it be guaranteed that another plugin cannot override the security plugin?

[cwperks]

If 2 NetworkPlugins are installed that both define getHttpTransports(), I believe its up to the cluster admin to define http.type in opensearch.yml.

The security plugin seems to get around the explicit need to set http.type by instead overriding Plugin.additionalSettings and setting NetworkModule.HTTP_TYPE_KEY

[reta]

@cwperks there could be as many HTTP transports installed as needed, however there is only one default transport: for example netty4 / nio / reactor-netty4 (upcoming). I think we need to find a way to expose the header verifier functionality in such a way that is not dependent on transport implementation but driven by transport APIs.

To say in another words, we need to have a hook / configuration somewhere in AbstractHTTPTransport that allows to inject header validation in predictable place no matter what transport is being used.

[stephen-crawford]

[Triage] Hi @cwperks, can you please add some exit criteria/action items for this issue? Thank you

[cwperks]

we need to have a hook / configuration somewhere in AbstractHTTPTransport that allows to inject header validation in predictable place no matter what transport is being used

I absolutely agree. That way, no matter which http.type is configured in opensearch.yml, there can be a generic place where the headers can be processed and a determination with how to proceed with the request for the given transport.

FYI with the netty-specific implementation of the header_verifier, there is fallback logic to continue doing auth as part of the last step of the pipeline (the request handler) where auth used to be performed here

[stephen-crawford]

[Triage] Looks like this question got answered. Going to close. Thank you for your investigation :)