On Wednesday, May 24, 2023 at 8:41:20 AM UTC-7 Wesley Hartford wrote: Thanks for getting back to me, Sanjay. As far as I can tell, my client and server are both using the appropriate Xds credentials: The client code is at https://github.com/wfhartford/kotlin-grpc-xds/blob/18598a7e9210be7265bc753b136cb424d087ab77/client/src/main/kotlin/ca/cutterslade/kotlingrpcxds/client/main.kt#L26 Grpc.newChannelBuilder(targetUrl, XdsChannelCredentials.create(InsecureChannelCredentials.create())).build()
The server code is at https://github.com/wfhartford/kotlin-grpc-xds/blob/18598a7e9210be7265bc753b136cb424d087ab77/server/src/main/kotlin/ca/cutterslade/kotlingrpcxds/server/main.kt#L45 XdsServerBuilder.forPort(8443, XdsServerCredentials.create(InsecureServerCredentials.create())) The insecure credentials provided to both a fallback, and it looks like the sample you linked is doing the same thing. Yes, you are right - Xds credentials are being correctly used so that's not an issue. I'm not sure why, but I'm guessing that the secure connection is failing and it is falling back to insecure. No, that cannot be the case. As described here https://github.com/grpc/proposal/blob/master/A29-xds-tls-security.md#programming-api fallback credentials are *not* meant to be used when secure connection fails. If you suspect that's happening can you provide some evidence (logs etc)? Based on the example you linked, the only other requirement is that the GRPC_XDS_BOOTSTRAP environment variable is set, which is being done by the istio sidecar; kubectl describe pod shows that both the client and server containers have two environment variables injected: GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORT: true GRPC_XDS_BOOTSTRAP: /etc/istio/proxy/grpc-bootstrap.json The bootstrap file (and the GRPC_XDS_BOOTSTRAP environment variable) is required not just for security but overall XDS support. Based on your observations in the first email it looks like client and server are able to communicate based on xds configuration so that part must be working. Just to confirm your client did use the "xds:///" prefix to access your service, right? If you are certain that XDS is working for load balancing and plaintext communication but breaks only when mTLS is enabled it might be useful to enable debug logging on both client and server side (for the io.grpc.xds package and below). Also you can check the contents of /etc/istio/proxy/grpc-bootstrap.json esp. the certificate_providers part and confirm that the 3 files provided in the config have valid certificate material. Let me know if you need help debugging that part. There are only two warning lines being logged from both the client and the server: 14:51:55.314 [main] WARN i.g.n.s.io.netty.bootstrap.Bootstrap - Unknown channel option 'SO_KEEPALIVE' for channel '[id: 0xba433026]' 14:51:55.314 [main] WARN i.g.n.s.io.netty.bootstrap.Bootstrap - Unknown channel option 'io.grpc.netty.shaded.io.netty.channel.epoll.EpollChannelOption#TCP_USER_TIMEOUT' for channel '[id: 0xba433026]' I doubt this is an issue. Just to confirm you see these messages also when mTLS is not enabled, right? Do you know of anything else I might be missing that is required for a secure connection? Thanks, Wesley -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5a062461-2c73-4475-b99c-ddfe43a569e6n%40googlegroups.com.
