fix: plumb mtls endpoint to TransportChannelProvider #3673
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rmehta19
commented
Mar 4, 2025
| @@ -258,6 +260,11 @@ public boolean needsEndpoint() { | |||
| return endpoint == null; | |||
| } | |||
|
|
|||
| @Override | |||
| public boolean needsMtlsEndpoint() { | |||
| return mtlsEndpoint == null; | |||
There was a problem hiding this comment.
If we want, I think we could make this:
return (mtlsEndpoint == null) && (useS2A == true)
That way, we can be sure we are only setting the mtlsEndpoint when we know:
- it is non-null
- it is non-empty
- it is needed by S2A
Note that the first two are checked in shouldUseS2A in EndpointContext.
|
@lqiu96 , please review, thanks! |
rmehta19
changed the title
|
Friendly ping @lqiu96 . Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR plumbs the MTLS endpoint (separately from the resolved endpoint) from the
EndpointContextto theInstantiatingGrpcChannelProvider.Why not just set the MTLS endpoint in
EndpointContextif S2A can be used?EndpointContext, we could fail to use S2A inInstantiatingGrpcChannelProvider(if autoconfig doesn't return an address), in which case we fall back to using a TLS connectionInstantiatingGrpcChannelProvider, and the decision to use DirectPath is made inInstantiatingGrpcChannelProvider, notEndpointContext. We may decide to use S2A inEndpointContext, but when we go to create the channel inInstantiatingGrpcChannelProvider, we may find that we should be using DirectPath, in which case we need to use the non-MTLS endpoint