Mutual TLS Migration
In the scenario where there are many services communicating over the network, itmay be desirable to gradually migrate them to Istio. During the migration, some services have Envoysidecars while some do not. For a service with a sidecar, if you enablemutual TLS on the service, the connections from legacy clients (i.e., clients withoutEnvoy) will lose communication since they do not have Envoy sidecars and client certificates.To solve this issue, Istio authentication policy provides a “PERMISSIVE” mode to solvethis problem. Once “PERMISSIVE” mode is enabled, a service can take both HTTPand mutual TLS traffic.
You can configure Istio services to send mutualTLS traffic to that service while connections from legacy services will notlose communication. Moreover, you can use theGrafana dashboard to check which services arestill sending plaintext traffic to the service in “PERMISSIVE” mode and choose to lockdown once the migration is done.
Understand Istio and related mutual TLS authentication concepts.
Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use the demo configuration profile as described in, or set the installation option to false).
For demo
$ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done
sleep.foo to httpbin.foo: 200
sleep.bar to httpbin.foo: 200
sleep.legacy to httpbin.foo: 200
- Also verify that there are no authentication policies or destination rules (except control plane’s) in the system:
$ kubectl get policies.authentication.istio.io --all-namespaces
NAMESPACE NAME AGE
istio-system grafana-ports-mtls-disabled 3m
Configure Istio services to send mutual TLS traffic by setting DestinationRule
.
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "example-httpbin-istio-client-mtls"
host: httpbin.foo.svc.cluster.local
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
EOF
Now we confirm all requests to httpbin.foo
still succeed.
$ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done
200
200
200
You can also specify a subset of the clients’ request to use ISTIO_MUTUAL
mutual TLS inDestinationRule
.After verifying it works by checking ,then increase the rollout scope and finally apply to all Istio client services.
After migrating all clients to Istio services, injecting Envoy sidecar, we can lock down the httpbin.foo
to only accept mutual TLS traffic.
Now you should see the request from sleep.legacy
fails.
$ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done
200
200
503
If you can’t migrate all your services to Istio (injecting Envoy sidecar), you have to stay at 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 Authorization to configure different paths with different authorization policies.
Remove all resources.
Namespaces foo bar legacy deleted.
Shows you how to use Istio authentication policy to setup mutual TLS and basic end-user authentication.
Shows how to migrate from one trust domain to another without changing authorization policy.
Describes Istio's authorization and authentication functionality.
Provision and manage DNS certificates in Istio.
Introducing the Istio v1beta1 Authorization Policy
Introduction, motivation and design principles for the Istio v1beta1 Authorization Policy.