I looked at the logs and I can confirm that the client is not using mTLS
because Istio didn't provide the right configuration. Let me explain:
>From your server-mtls-strict.log I see this
"transportSocket": {
"name": "envoy.transport_sockets.tls",
"typedConfig": {
I've attached a copy of the log files with xds logging set to trace for an
execution of the client and server with istio's mtls mode set to STRICT and
PERMISSIVE. My interpretation of these logs is:
In PERMISSIVE mode, neither client nor server is trying to use any type of
TLS; they're both using
(adding grpc.io group back)
On Wed, May 24, 2023 at 2:57 PM Wesley Hartford
wrote:
> Hi,
>
> My suggestion that the connection was falling back to insecure was not
> evidence based, I'm still trying to wrap my head around how all this is
> working.
>
Okay.
>
> The target address on the
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
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
On Wednesday, May 17, 2023 at 11:07:43 AM UTC-7 Wesley Hartford wrote:
...
What doesn't seem right:
- A server interceptor reports that ServerCall.getSecurityLevel()
returns NONE,
Seems right when you are using InsecureChannelCredentials i.e. plaintext.
- When I configure
