qq, I noticed that this rough logic also exists here and in the EndpointContext. What's the reason that it needs to exist in the gRPC Channel Provider as well as EndpointContext?

Yes good question. The issue is that EndpointContext is responsible for "endpoint resolution", which takes a dependency on the availability of mTLS (i.e. use mTLS endpoint only if mTLS support is available) - see the complicated "determineEndpoint" function. In the other 2 locations (gRPC/HTTP channel provider), they are used for configuring the TLS settings of the Channel themselves.

In the other 2 locations (gRPC/HTTP channel provider), they are used for configuring the TLS settings of the Channel themselves.

Sorry, can you elaborate on this point? I wasn't aware there was settings that MtlsProvider itself was configuring anything. Can you link me to how it's configure TLS settings on the channel?

My assumption was that it was only using the MtlsProvider logic (i.e. checking for env var) to see if Mtls was to be enabled and not touching anything on the channel.

Let me clarify, for gRPC/HTTP channel provider, the "mtlsKeyStore" is used for creating the mTLS-enabled transport as seen in the code snippet below:

HttpTransport createHttpTransport() throws IOException, GeneralSecurityException {
if (certificateBasedAccess == null || mtlsProvider == null) {
return null;
}
if (certificateBasedAccess.useMtlsClientCertificate()) {
KeyStore mtlsKeyStore = mtlsProvider.getKeyStore();
if (mtlsKeyStore != null) {
return new NetHttpTransport.Builder().trustCertificates(null, mtlsKeyStore, "").build();
}
}
return null;
}

The channel providers have no reference to the EndpointContext, so need to independently calculate and bootstrap the mTLS provider.

I see, thanks for the explanation.

In this case, I think what we have previously configured is probably a mistake (i.e. configuring multiple separate MtlsProviders). I think realistically the flow should be

1. EndpointContext creates the MtlsProvider and CertificateBasedAccess class that is used to compute the endpoint
2. gRPC and HttpJson channel providers get the MtlsProvider and CertificateBasedAccess classes that were created in the endpointcontext

However, I think in order for that to be done, we'll need to create public methods inside TransportChannelProvider to allow access to them. It is possible with adding InternalApi and we have done previously to access mtlsEndpoint.

Let me think about the options a bit more. I think what you have is based on the existing code and should work, but I think it previously wasn't configured the best/ correctly and would love to try and fix it if possible.

Thanks @andyrzhao, taking a look at this and I don't think there is a clear best way to do this.

Since it looks like these implementations (EndpointContext, GrpcChannelProvider, HttpJsonChannelProvider) are private implementations and not accessible to customers, I think I'm fine with keep it as-is. Adding public methods to clean this up can be done in a future time and perhaps a better implementation can also be found. The new implementation follows the old one and I don't think this would be a regression.

Would you mind creating an issue in our repo to track that future enhancement?

Thanks Lawerence! Created #3872