Mutual TLS Migration
This task shows how to ensure your workloads only communicate using mutual TLS as they are migrated to Istio.
Istio automatically configures workload sidecars to use mutual TLS when calling other workloads. By default, Istio configures the destination workloads using PERMISSIVE
mode.
When PERMISSIVE
mode is enabled, a service can accept both plaintext and mutual TLS traffic. In order to only allow
mutual TLS traffic, the configuration needs to be changed to STRICT
mode.
You can use the Grafana dashboard6 to
check which workloads are still sending plaintext traffic to the workloads in PERMISSIVE
mode and choose to lock
them down once the migration is done.
Before you begin
Understand Istio authentication policy and related mutual TLS authentication concepts.
Read the authentication policy task7 to learn how to configure authentication policy.
Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (for example, use the
default
configuration profile as described in installation steps8).
In this task, you can try out the migration process by creating sample workloads and modifying the policies to enforce STRICT mutual TLS between the workloads.
Set up the cluster
Create two namespaces,
foo
andbar
, and deploy httpbin9 and curl10 with sidecars on both of them:Create another namespace,
legacy
, and deploy curl10 without a sidecar:Verify the setup by sending http requests (using curl) from the curl pods, in namespaces
foo
,bar
andlegacy
, tohttpbin.foo
andhttpbin.bar
. All requests should succeed with return code 200.
Lock down to mutual TLS by namespace
After migrating all clients to Istio and injecting the Envoy sidecar, you can lock down workloads in the foo
namespace
to only accept mutual TLS traffic.
Now, you should see the request from curl.legacy
to httpbin.foo
failing.
If you installed Istio with values.global.proxy.privileged=true
, you can use tcpdump
to verify
traffic is encrypted or not.
You will see plain text and encrypted text in the output when requests are sent from curl.legacy
and curl.foo
respectively.
If you can’t migrate all your services to Istio (i.e., inject Envoy sidecar in all of them), you will need to continue to use PERMISSIVE
mode.
However, when configured with PERMISSIVE
mode, no authentication or authorization checks will be performed for plaintext traffic by default.
We recommend you use Istio Authorization13 to configure different paths with different authorization policies.
Lock down mutual TLS for the entire mesh
You can lock down workloads in all namespaces to only accept mutual TLS traffic by putting the policy in the system namespace of your Istio installation.
Now, both the foo
and bar
namespaces enforce mutual TLS only traffic, so you should see requests from curl.legacy
failing for both.
Clean up the example
Remove the mesh-wide authentication policy.
Remove the test namespaces.