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
xds/clusterresolver: set ServerName to an address for LogicalDNS #5793
Closed
Closed
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
40ec788
transport: new stream with actual server name
holdno 2b12d75
renamed and add test for: transport: ensure value of :authority heade…
holdno 95a427b
fix: copy callHdr to resolve race
holdno 4cbfed1
remove and modify valueless comments
holdno 6f29d4e
move resolver authority test to e2e test
holdno acdbf62
restore transport/transport_test.go
holdno 56e5899
modify test notes
holdno 3d99b17
fix: undefined resolver
holdno 8429bb7
xds/clusterresolver: set a ServerName to an address for LogicalDNS
110y File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
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
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
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.
This PR just adds this change.
Other changes are inherited from #5748 as I described in the description of this PR.
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.
Our current behavior (which is to set the
:authority
header to the authority on the channel and not the DNS name received as part of the Cluster resource) was an explicit choice. It is a fairly serious security risk to set it to the DNS name received from the Cluster resource.We are going to be investigating this further at some point to support certain serverless use cases. But it's not yet clear to us, how we will solve the security problem here. We'll definitely need more design work before we can safely do something like this. And when we have a design for this, we will publish a gRFC for the same, and the change will happen across all supported gRPC languages.
Unfortunately, we cannot accept this PR at this point in time.
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.
Please feel free to engage with the gRPC team on our mailing list if you want to continue this discussion and work towards a secure solution for this problem. Thank you.
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.
@easwars
Thank you for your review!
Could you please let me know the risk regarding this change briefly...?
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.
In general, the authority for the connection is used to verify the peer -- e.g., for TLS, the client checks that the server's certificate matches that authority. Because of that, we essentially view it as a requirement that the authority be explicitly specified by the client application (either via the target URI used to create the channel or via an explicit channel option indicating the authority to use) rather than coming from some external control plane (e.g., being specified by the resolver or by an LB policy), because otherwise we would basically give a compromised control plane the ability to tell us to talk to some arbitrary endpoint without us actually verifing that the endpoint is authenticated as the intended peer.