GoogleDefaultChannelBuilder does not support user-provided CallCredentials

[ejona86]

GoogleDefaultChannelBuilder overrides the CallCredentials on CallOptions. This means that the user can't supplement the credential. Other languages will perform the union of the CallCredentials in the CallOptions and the GoogleDefaultCreds.

CC @jiangtaoli2016

[apolcyn]

Is a union of call creds, when the user provides them, a proposal here? C's google default creds don't allow user-provided call creds at all.

[jiangtaoli2016]

In gRPC C core, when using GoogleDefaultCredentials, it will automatically use default channel credential and default call credentials (OAuth2 token).

User can put additional metadata credentials per RPC using MetadataCredentialsPlugin (grpc_metadata_credentials_plugin)

@markdroth correct me if I am wrong.

[andreamlin]

Please take a look at googleapis/gax-java#650

[apolcyn]

I suppose one might be able to compose a google default creds C object with another custom call creds, but is that the desired functionality? I.e. is the idea here to combiner the call creds that google default creds uses, with a user-provided one, or to have the user-provided one override the default call creds of google default creds?

[ejona86]

@apolcyn, since the beginning of the auth API I was told union is what was "expected" (by the people writing this code, not by users) and that's why ChannelCredentials are unioned with CallCredentials specified per-RPC. That seemed bizarre to me, but it was arguing in a vacuum. At this point it is part of all C-core derived languages, so it would probably need a new API to change the behavior.

[apolcyn]

Hmm, might be seeing this differently, but to me the ability to union channel credentials with call credentials in C-core derived languages is one thing, but this issue is specific to the fact that google default credentials "internally-composed creds" don't have overrideable call creds. If we union call creds and have the user-provided one run after the google call creds one, then I suppose that would work - but I do think it sounds surprising. FWIW, none of the C wrapped languages currently expose C-core's "google default credentials", C++ is the only surface API that exposes it.

[ejona86]

@apolcyn, in C-based languages, ChannelCreds can include CallCreds. When you specify ChannelCreds that contain CallCreds when creating a new Channel, then if you specify per-RPC CallCreds you will get the union of both sets of CallCreds. So in all C-based languages you cannot override the CallCreds.

Yes, I understand that the wrapped languages aren't directly exposing the C-core implementation, but they cloned the behavior or are wrapping the behavior (e.g., CreateNativeCredentials in C#).

[ejona86]

@apolcyn and I talked offline. He was pointing out that today GAX isn't using GoogleDefaultCredentials if the user specifies custom credentials.

For example, in Java:

https://github.com/googleapis/google-cloud-java/blob/7fc4b3b2973faa23292b4f92f49ef1445d19934d/google-cloud-clients/google-cloud-core/src/main/java/com/google/cloud/ServiceOptions.java#L272

[andreamlin]

@ejona86 Does this mean a patch isn't needed?

[ejona86]

@andreamlin, it means that the cloud libraries might need to use ManagedChannelBuilder if the user specifies a Credential and by default use GoogleDefaultChannelBuider. With that, the limitation of GoogleDefaultChannelBuilder wouldn't impact the cloud libraries (it would still be present, but the cloud libraries wouldn't trigger it).