-
Notifications
You must be signed in to change notification settings - Fork 60
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
fix: DirectPath calls do not duplicate the request metadata #3663
base: main
Are you sure you want to change the base?
Changes from 1 commit
54888f6
590e2aa
c433ce9
c062bc6
8c854f7
62014ca
264a123
6618a1b
d30d692
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -650,6 +650,9 @@ private ManagedChannel createSingleChannel() throws IOException { | |
} | ||
if (channelCredentials != null) { | ||
// Create the channel using channel credentials created via DCA. | ||
channelCredentials = | ||
CompositeChannelCredentials.create( | ||
channelCredentials, MoreCallCredentials.from(credentials)); | ||
builder = Grpc.newChannelBuilder(endpoint, channelCredentials); | ||
} else { | ||
// Could not create channel credentials via DCA. In accordance with | ||
|
@@ -665,11 +668,18 @@ private ManagedChannel createSingleChannel() throws IOException { | |
// which will be used to fetch MTLS_S2A hard bound tokens from the metdata server. | ||
channelCredentials = | ||
CompositeChannelCredentials.create(channelCredentials, mtlsS2ACallCredentials); | ||
} else { | ||
channelCredentials = | ||
CompositeChannelCredentials.create( | ||
channelCredentials, MoreCallCredentials.from(credentials)); | ||
} | ||
builder = Grpc.newChannelBuilder(endpoint, channelCredentials); | ||
} else { | ||
// Use default if we cannot initialize channel credentials via DCA or S2A. | ||
builder = ManagedChannelBuilder.forAddress(serviceAddress, port); | ||
// Use default TLS credentials if we cannot initialize channel credentials via DCA or S2A. | ||
channelCredentials = | ||
CompositeChannelCredentials.create( | ||
TlsChannelCredentials.create(), MoreCallCredentials.from(credentials)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. qq, for this flow, shouldn't it be just Why does it need to be done via CompositeChannelCredentials? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh wait.. This is because we were sending the GoogleCredentials as part of CallOptions. NVM I think this is correct. |
||
builder = Grpc.newChannelBuilderForAddress(serviceAddress, port, channelCredentials); | ||
} | ||
} | ||
} | ||
|
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 think the one main concern about this is that this is a behavior breaking change if there are uses that manually create a GrpcCallContext and use
withCredentials
. I don't think there are really any valid uses cases for this, but I will need to check for this.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.
Yes that makes sense.
What's also concerning is, by looking at the CI failures, it seems many tests have been building the channel from
InstantiatingGrpcChannelProvider
without actually giving it a credentials. AndMoreCallCredentials.from()
throws exception for null credentials.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.
Those showcase tests seems to be fixable within this PR. But I'm unsure about the downstream compatibility tests and those on Cloud Build (I lack permission to view logs).
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.
The showcase tests were following this: https://github.com/googleapis/gapic-showcase?tab=readme-ov-file#example-for-java-grpc
Essentially it's a local server that is not expected to do any authentication. I think we just need a way to be able to hit the local server with no credentials provided.
The downstream tests for our partner teams is a bit concerning. I think we'll need to investigate them to see if they're just a testing configuration issue or a logic issue.
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.
Would it make sense if we allow
null
credentials in the case of one-way TLS? I believe there are no valid use cases to go without credentials here when mTLS or DirectPath are used.Agreed.
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 realize a tricky thing we missed earlier.
The API
setChannelConfigurator
takes an option that gets applied to the channel builder. In various tests (downstream or showcase),ManagedChannelBuilder::usePlainText
is given. While users are not supposed to use insecure channels in production, this is reasonable and often convenient in tests when the server is turned on locally. This change is breaking that behavior.Basically, either we have to change all tests (setting up TLS can be difficult), or we need a way to allow insecure channels w/ credentials, and
TlsChannelCredentials.create()
doesn't support that. For the second approach, IIUC, it goes back to the need of supporting adding call credentials to a managed channel builder that is possibly configured to build insecure channels. cc: @ejona86There 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.
Using
InsecureChannelCredentials.create()
instead of TlsChannelCredentials would be fine for those specific tests. But the existing sdk API works poorly for that.You can add CallCredentials per-RPC, either on the stub, in the CallOptions, or with an interceptor (that adds it to the CallOptions).
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.
Yes unfortunately the existing SDK API doesn't take
InsecureChannelCredentials
explicilty.The client SDK has been attaching call credentials to the CallOptions. Now the problem is that DirectPath (via
GoogleDefaultChannelCredentials
) gets or creates its own call credentials. So currently, this is causing the same request metadata to appear twice. Because we want to adopt bound credentials in DirectPath, it's not ideal to change thisGoogleDefaultChannelCredentials
to build without call credentials. Nor would it be good for backward compatibility reasons.So as this PR is trying to do, we want to stop attaching call credentials to CallOptions in all gRPC cases. But then we need to make sure all gRPC cases can get the call credentials from the channel.
ManagedChannelBuilder
doesn't allow it. This is where we are stuck.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.
You can add an interceptor to the channel that attaches CallCreds to the CallOptions.
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.
Ah. I didn't realize this from your first comment. Will try it. Thanks!