xds: Support custom credentials using XdsCredentialsRegistry #8924
Conversation
using the XdsCredentialsRegistry. XdsCredentialsRegistry uses Java Service Provider mechanism to load providers(XdsCredentialProvider) at runtime. The XdsCredentialsRegistry will replace the hardcoded list of credentials currently being used in Xds Bootstrapper.
…this in the documentation of XdsCredentialProvider
…dsCredentialProviders as experimental
|
@anicr7 what does it take to also add support for the Istio/K8S use-case where grpc would use:
It will be very good to get that support in. CC @costinm |
cc: @markdroth, @ejona86, @dfawley Sanjay, However you would have to clearly define/document the parameters that can be passed in for different credentials and that would be majority of the effort involved here. |
|
There are 2 problems for connecting to a XDS server ( like Istio, but other implementations of XDS exist and could be used):
IMO a more generic mechanism to allow user to customize the XDS client would be great - some users may use other ecosystem features like metrics, traces - on the XDS client connection. But while a plugin allowing custom code is great - having a built-in file for JWT and root cert would be great. |
|
@ejona86 Friendly ping :). |
xds/src/main/java/io/grpc/xds/internal/GoogleDefaultXdsCredentialsProvider.java
Show resolved
Hide resolved
xds/src/test/java/io/grpc/xds/internal/GoogleDefaultXdsCredentialsProviderTest.java
Show resolved
Hide resolved
…move error message about proguard
1. Rename the function from getChannelCredentials to newChannelCredentials instead. 2. Add a test case to make sure the relevant xds credentials are available through Service loader 3. Change bootstrapper to pass in config map instead of the complete channel credentials json map. 4. Add some documentation about the wrapper xds credentials.
|
To be clear to other commenters: This PR just allows the pre-existing bootstrap plugin functionality to be supplemented at runtime with xDS not needing a hard dependency on each credential type. Creating a CallCredentials registry to allow JWT or enhancing TlsChannelCredentials to support an option to specify root certs are possible, but would require a cross-language design and is outside the scope of this PR. |
|
@anicr7, I copied the PR description to the commit description, since the PR description seemed more complete. It is generally useful to write a nice commit description and have it auto-copied when constructing the PR. |
Thanks Eric! |
and using Immutable interface types. 1. Unnecessary fully qualified names Currently in XdsCredentialsRegistry, the child classes are referred by their fully qualified names i.e. 'io.grpc.xds.internal.GoogleDefaultXdsCredentialsProvider' instead of importing GoogleDefaultXdsCredentialsProvider and just using GoogleDefaultXdsCredentialsProvider.class. 2. Use immutable interfaces instead of the generic collection interface i.e. ImmutableMap instead of just Map. These improvements are related to grpc#8924.
and using Immutable interface types. 1. Unnecessary fully qualified names Currently in XdsCredentialsRegistry, the child classes are referred by their fully qualified names i.e. 'io.grpc.xds.internal.GoogleDefaultXdsCredentialsProvider' instead of importing GoogleDefaultXdsCredentialsProvider and just using GoogleDefaultXdsCredentialsProvider.class. 2. Use immutable interfaces instead of the generic collection interface i.e. ImmutableMap instead of just Map. These improvements are related to grpc#8924.
…es and using Immutable interface types. (#9025) 1. Unnecessary fully qualified names Currently in XdsCredentialsRegistry, the child classes are referred by their fully qualified names i.e. 'io.grpc.xds.internal.GoogleDefaultXdsCredentialsProvider' instead of importing GoogleDefaultXdsCredentialsProvider and just using GoogleDefaultXdsCredentialsProvider.class. 2. Use immutable interfaces instead of the generic collection interface i.e. ImmutableMap instead of just Map. These improvements are related to #8924.
Currently the credentials used for xDS communications is hardcoded in the BootstrapperImpl. The bootstrap config chooses one of the possible hardcoded credential. This commit adds support for a credential plugin which allows users to register custom credentials through XdsCredentialProviders. gRPC will automatically discover the implementations via Java's SPI mechanism Bootstrapper will use XdsCredentialRegistry to retrieve the list of supported credentials. The current hardcoded list of credentials(google_default, insecure and tls) are registered by default to keep the behavior as is.
Currently the credentials used for xDS communications is hardcoded in the BootstrapperImpl. The bootstrap config chooses one of the possible hardcoded credential.
This PR adds support for a credential plugin which allows users to register custom credentials through XdsCredentialProviders. gRPC will automatically discover the implementations via Java's SPI mechanism
Bootstrapper will use XdsCredentialRegistry to retrieve the list of supported credentials. The current hardcoded list of credentials(google_default, insecure and tls) are registered by default to keep the behavior as is.