Envoy's access log and mTLS verification

[dziqrosomaq]

Hey,
Istio is some kind of magic. We wanted to enable mTLS between services. Created PeerAuthentication in STRICT mode and BAM - it works. At least it should be working, according to the documentation. Beside of that we can see padlock icons at Grafana and Kiali UI. Nevertheless, I felt like I need some logging/audit proof that our workloads are connecting with each other using mTLS.

I found the topic:

Verifying mTLS between services

Thank you, all. I ended up updating the log format, per @kuat’s suggestion . I added the following: localSubject=%DOWNSTREAM_LOCAL_SUBJECT% peerSubject=%DOWNSTREAM_PEER_SUBJECT% peerIssuer=%DOWNSTREAM_PEER_ISSUER%i localUriSan=%DOWNSTREAM_LOCAL_URI_SAN% peerUriSan=%DOWNSTREAM_PEER_URI_SAN% This is what the receiving istio-proxy’s log looks like. I don’t know why the subjects are missing, but I do see other fields. [03/03/2020T18:28:16+0000 1583260096] method=GET authority=hiworld.hw:5000 t…

suggesting that I should read Envoy’s access log.

Ok, I’m on it. But wait. This guide Istio / Envoy Access Logs does not describe how to enable access logs for Helm installation (and that’s the one I need). The term “accessLogFile” occurs only once in regards to the demo profile in following directory https://github.com/istio/istio/tree/master/manifests

Can you help me with accessing the access log and/or verifying enabled mTLS? When I send http request from one workload to another in a mesh that’s configured to enforce mTLS, I’d like to know what was the TLS version and cipher suite used when Istio was doing its job, tunnelling http over https

Regards

[SujaiSD]

Run a pod without TLS and try to connect using curl. It won’t allow you to connect, do your debugging from the new pod that you used for the testing.

This can be a pod created just using kubectl command only for testing, not required to be part of your application.