-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Implement using system root trust ca for TLS server authentication for XDS #11470
base: master
Are you sure you want to change the base?
Changes from all commits
5433ebb
c836168
240ce31
3c02531
64e6cef
dfbc812
29a4fbf
1eca009
4ac8dd6
c7bc172
8feb398
39b07c3
b968088
8acab09
5c68d01
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 |
---|---|---|
|
@@ -16,8 +16,6 @@ | |
|
||
package io.grpc.xds.internal.security.certprovider; | ||
|
||
import static com.google.common.base.Preconditions.checkNotNull; | ||
|
||
import io.envoyproxy.envoy.config.core.v3.Node; | ||
import io.envoyproxy.envoy.extensions.transport_sockets.tls.v3.CertificateValidationContext; | ||
import io.envoyproxy.envoy.extensions.transport_sockets.tls.v3.CommonTlsContext; | ||
|
@@ -46,7 +44,7 @@ final class CertProviderClientSslContextProvider extends CertProviderSslContextP | |
node, | ||
certProviders, | ||
certInstance, | ||
checkNotNull(rootCertInstance, "Client SSL requires rootCertInstance"), | ||
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. CertProviderSslContextProvider.isMtls() can return the wrong value when rootCertInstance is null but the system root certs should be used. I don't know what that is used for, but have you check through the class to make sure the null is handled correctly? 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. There are usages of isMtls() /isClientSideTls()/isServerSideTls() for updating the SslContext. The usage of isMtls() in client cert provider for setting the keyManager is impacted by the change, and is rather done better with the check if (savedKey != null) instead of if (isMtls()). The usages in the base class CertProviderSslContextProvider of isMtls() / isClientSideTls() / isServerSideTls() is very confusing to me, since both the client side and server side providers inherit from it (i.e. since a connection has a Xds client and a Xds server, will calling any of these methods on either party should return the same result, it doesn't look like it). Each of these usages also have a further nested check based on savedKey or savedTrustedRoots, I think the inner if conditions can just be used by themselves without the check first for sMtls() / isClientSideTls() / isServerSideTls(), unless those checks achieve anything meaningful. 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. For the usages in the base class CertProviderSslContextProvider that I mentioned above can we use only the inner if conditions nested under each of the isMtls() / isClientSideTls() / isServerSideTls() calls? 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.
Well, that's assuming we notice the issue if/when we add server support. It looks like we should get rid of 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. I realized the trio of methods isMtls() / isClientSideTls() / isServerSideTls() help do 2 things -
I think the easy way and the only thing needed is to augment isMtls() to
I have also introduced a test for Mtls with system roots for the client: XdsSecurityClientServerTest::tlsClientServer_useSystemRootCerts_requireClientAuth. |
||
rootCertInstance, | ||
staticCertValidationContext, | ||
upstreamTlsContext, | ||
certificateProviderStore); | ||
|
@@ -56,12 +54,15 @@ final class CertProviderClientSslContextProvider extends CertProviderSslContextP | |
protected final SslContextBuilder getSslContextBuilder( | ||
CertificateValidationContext certificateValidationContextdationContext) | ||
throws CertStoreException { | ||
SslContextBuilder sslContextBuilder = | ||
GrpcSslContexts.forClient() | ||
.trustManager( | ||
new XdsTrustManagerFactory( | ||
savedTrustedRoots.toArray(new X509Certificate[0]), | ||
certificateValidationContextdationContext)); | ||
SslContextBuilder sslContextBuilder = GrpcSslContexts.forClient(); | ||
// Null rootCertInstance implies hasSystemRootCerts because of the check in | ||
// {@link CertProviderClientSslContextProviderFactory}. | ||
if (rootCertInstance != null) { | ||
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. Let's have a comment describing that null rootCertInstance implies hasSystemRootCerts because of ClientSslContextProviderFactory. 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. Done. |
||
sslContextBuilder.trustManager( | ||
new XdsTrustManagerFactory( | ||
savedTrustedRoots.toArray(new X509Certificate[0]), | ||
certificateValidationContextdationContext)); | ||
} | ||
if (isMtls()) { | ||
sslContextBuilder.keyManager(savedKey, savedCertChain); | ||
} | ||
|
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.
We should move this check into
certProviderClientSslContextProviderFactory.getProvider()
. That makes it more obvious what is going on and avoids deletingtestProviderForClient_rootInstanceNull_expectError()
. It'd be fine to move the checkNotNull checks togetProvider()
as well.(Although it looks like
upstreamTlsContext.getCommonTlsContext()
can never be null (except in tests), because proto won't return a null message, so UpstreamTlsContext.fromEnvoyProtoUpstreamTlsContext() will never pass null to the UpstreamTlsContext constructor. I see BaseTlsContext has the field mark@Nullable
, but it looks to never be null. We could potentially add a checkNotNull to BaseTlsContext instead of checking for null here.)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.
Done.