-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alts: Make GoogleDefaultChannelCredentials take a CallCredentials #8548
Merged
Merged
Changes from 7 commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
6a8ad79
alts: Make ComputeEngineChannelCredentials take a CallCredentials as …
mohanli-ml 189dfce
alts: Make ComputeEngineChannelCredentials take a CallCredentials
mohanli-ml a3f4724
alts: Make ComputeEngineChannelCredentials take a CallCredentials
mohanli-ml 5f5abaf
Merge branch 'master' into compute-engine-creds
mohanli-ml 2893db7
alts: Make ComputeEngineChannelCredentials take a CallCredentials
mohanli-ml 5153201
alts: Make ComputeEngineChannelCredentials take a CallCredentials
mohanli-ml 0d1fd71
alts: Make ComputeEngineChannelCredentials take a CallCredentials
mohanli-ml b229d4f
alts: Make GoogleDefaultChannelCredentials take a CallCredentials
mohanli-ml 8cb0153
alts: Make GoogleDefaultChannelCredentials take a CallCredentials
mohanli-ml 045743f
alts: Make GoogleDefaultChannelCredentials take a CallCredentials
mohanli-ml 0d6658e
Merge branch 'master' into compute-engine-creds
mohanli-ml 6b7d3ca
alts: Make GoogleDefaultChannelCredentials take a CallCredentials
mohanli-ml File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... This is a bit interesting, as if the user is providing call credentials we could actually work on non-GCE.
I wonder if we are modifying the wrong API, and should be modifying GoogleDefaultChannelCredentials instead. CC @menghanl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gax-java and google-api-go-client will check the GCP environment before attempting DirectPath, see https://github.com/googleapis/gax-java/blob/main/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java#L336 and https://github.com/googleapis/google-api-go-client/blob/master/transport/grpc/dial.go#L141.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, or we should just add a general purpose API that accepts callCreds.
And both
GoogleDefaultCreds
andComputeEngineCreds
should be built on that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of this? grpc/grpc-go#4830
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what? That has little to do with the implementation and times it could be used. The point is that this API has no dependency on GCE when you provide the credentials.
I think that is essentially "GoogleDefaultCreds with passed call creds" like I was suggesting. And it seems that is the approach you took with grpc/grpc-go#4830, so I think we are on the same page.
We should modify GoogleDefaultChannelCredentials in Java instead of ComputeEngineChannelCredentials.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I have two concerns here:
Your opinion is from the perspective of API design, which makes sense to me. However, if you look from the perspective of DirectPath, since DirectPath can only be used on GCE, removing the checking on GCE in credentials (i.e., using GoogleDefaultCreds instead of ComputeEngineCreds) means that we relies on client libraries (i.e., the two links above) to check the GCE environment. I doubt if this is a good design, and I feel the secure solution here is to rename ComputeEngineCreds in this PR to DirectPathCreds (if ComputeEngineCreds is only used by DirectPath, and if not we can just create a new API), so that it will makes sense that the new API can take call credentials while also have dependency on GCE. WDYT? Also @menghanl
I remember originally we first developed GoogleDefaultCreds, but as client libraries owners wanted to know for sure what mechanism would be used to retrieve the OAuth token, so we then developed ComputeEngineCreds. @apolcyn Alex may have more context here. If after discussing Q1 we still want to use GoogleDefaultCreds for DirectPath, we should reach to client libraries owners as same concerns may still exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For 1, as you mention, the only reason ComputeEngineChannelCredentials exists is because the client libraries wanted to convert from their version of ComputeEngine creds and guarantee that GoogleDefaultChannelCredentials didn't use some other sort of cred. GoogleDefaultChannelCredentials was designed to run anywhere.
For 2, if the client libraries are explicitly passing the call credentials they expect to be used, then there's no mis-alignment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with 2.
For 1 I want to double check, you think it is OK that DirectPath will use GoogleDefaultChannelCredentials, and since GoogleDefaultChannelCredentials does not do the on GCE check, we rely on client libraries to do the on GCE check, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know how I can say this any differently. GoogleDefaultChannelCredentials is fine to use outside of GCE. If client libraries only want to use it for GCE, that is fine and up to them. Both GoogleDefaultChannelCredentials and ComputeEngineChannelCredentials do not require ALTS to work; they will fall back to TLS if anything goes wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks for clarifying. I have updated the PR. PTAL.