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
Support tls
xDS credentials defined in gRFC A65
#6690
Comments
Apologies for missing Mark's follow-up in that issue, otherwise I would have reopened it. If you don't mind sending a PR for this, that would be amazing! Thanks! |
This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
Can you please mark that so that it doesn't get automatically closed? Thanks! |
We review P1 issues weekly, so this won't get lost even without the label. |
#6475 is also a duplicate (it predates this issue). |
FYI, note that Java's support is incomplete. I believe it supports the |
Thanks for pointing this out, I fixed the description. |
Pull request: #6757 |
#6757 has been merged. |
Use case(s) - what problem will this feature solve?
See use cases defined in A65: mTLS Credentials in xDS Bootstrap File, already implemented in C (grpc/grpc#33234). Java has had incomplete (no CA reloading, no client certs) support since before the gRFC (grpc/grpc-java#8924).
Proposed Solution
Implement the design in A65: mTLS Credentials in xDS Bootstrap File. This is probably a very easy change to xds/internal/xdsclient/bootstrap/bootstrap.go. Happy to contribute if you don't have that prioritized on your end.
Additional Context
This is a dup of #4515 which was mistakenly closed.
We are investigating moving to xDS for service discovery, and the ability to delegate security to the management server would be a very useful feature for migrating clients of an insecure service to TLS enabled servers transparently. This requires using
xdscreds.NewCredentials(...)
transport credentials, which is insecure if the management server itself is using an insecure channel (I'd even argue that it would be great for security to reject configuring xds transport creds when the management server uses insecure, but I guess that would be a breaking change, maybe not worth it).The text was updated successfully, but these errors were encountered: