How can I enable/disable mutual TLS after I installed Istio?
Can I enable mutual TLS for some services while leaving it disabled for other services in the same cluster?
Authentication policy can be mesh-wide (which affects all services in the mesh), namespace-wide (all services in the same namespace), or service specific. You can have policy or policies to set up mutual TLS for services in a cluster in any way as you want.
How can I verify that traffic is using mutual TLS encryption?
If you installed Istio with
values.global.proxy.privileged=true, you can use
tcpdump to determine encryption status. Also in Kubernetes 1.23 and later, as an alternative to installing Istio as privileged, you can use
kubectl debug to run
tcpdump in an ephemeral container. See Istio mutual TLS migration for instructions.
If mutual TLS is globally enabled, can non-Istio services access Istio services?
STRICT mutual TLS is enabled, non-Istio workloads cannot communicate to Istio services, as they will not have a valid Istio client certificate.
If you need to allow these clients, the mutual TLS mode can be configured to
PERMISSIVE, allowing both plaintext and mutual TLS.
This can be done for individual workloads or the entire mesh.
See Authentication Policy for more details.
How can I use Kubernetes liveness and readiness for pod health checks when mutual TLS is enabled?
If mutual TLS is enabled, HTTP and TCP health checks from the kubelet will not work without modification, since the kubelet does not have Istio-issued certificates.
There are several options:
Using probe rewrite to redirect liveness and readiness requests to the workload directly. Please refer to Probe Rewrite for more information. This is enabled by default and recommended.
Using a separate port for health checks and enabling mutual TLS only on the regular service port. Please refer to Health Checking of Istio Services for more information.
PERMISSIVEmode for the workload, so it can accept both plaintext and mutual TLS traffic. Please keep in mind that mutual TLS is not enforced with this option.
How to configure the lifetime for Istio certificates?
For the workloads running in Kubernetes, the lifetime of their Istio certificates is by default 24 hours.
This configuration may be overridden by customizing the
proxyMetadata field of the proxy configuration. For example:
Does Auto mutual TLS exclude ports set using "excludeInboundPorts" annotation?
traffic.sidecar.istio.io/excludeInboundPorts is used on server workloads, Istio still
configures the client Envoy to send mutual TLS by default. To change that, you need to configure
a Destination Rule with mutual TLS mode set to
DISABLE to have clients send plain text to those
MySQL Connectivity Troubleshooting
You may find MySQL can’t connect after installing Istio. This is because MySQL is a server first protocol,
which can interfere with Istio’s protocol detection. In particular, using
PERMISSIVE mTLS mode, may cause issues.
You may see error messages such as
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.
This can be fixed by ensuring
DISABLE mode is used, or that all clients are configured
to send mTLS. See server first protocols for more information.
Does Istio support authorization?
Yes. Istio provides authorization features for both HTTP and plain TCP services in the mesh. Learn more.
How to configure Istio Ingress to only accept TLS traffic?
By following the instructions in the Secure Ingress Traffic task, Istio Ingress can be secured to only accept TLS traffic.
Can I install Istio sidecar for HTTPS services?
Yes, you can. It works both with mutual TLS enabled and disabled.