mirror of https://github.com/istio/istio.io.git
Revise the mTLS migration page (#1970)
This commit is contained in:
parent
77817391c5
commit
ca7172e737
|
|
@ -5,10 +5,24 @@ weight: 80
|
|||
keywords: [security,authentication,migration]
|
||||
---
|
||||
|
||||
This task shows how to migrate your existing Istio services' traffic from plain text to mutual TLS without breaking live traffic.
|
||||
This task shows how to migrate your existing Istio services' traffic from plain
|
||||
text to mutual TLS without breaking live traffic.
|
||||
|
||||
In practice, a mesh consists of both Istio services (with Envoy sidecars) and services without Envoy sidecar(called "legacy" below for simplicity).
|
||||
A legacy service can't use Istio issued key/certificate to send mutual TLS traffic. We want to enable mutual TLS incrementally, safely.
|
||||
In the scenario where there are many services communicating over the network, it
|
||||
may be desirable to gradually migrate them to Istio. During the migration, some services have Envoy
|
||||
sidecars while some do not. For a service with a sidecar, if you enable
|
||||
mutual TLS on the service, the connections from legacy clients (i.e., clients without
|
||||
Envoy) 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 solve
|
||||
this problem. Once "PERMISSIVE" mode is enabled, a service can take both HTTP
|
||||
and mutual TLS traffic.
|
||||
|
||||
You can configure Istio services to send mutual
|
||||
TLS traffic to that service while connections from legacy services will not
|
||||
lose communication. Moreover, you can use the
|
||||
[Grafana dashboard](/docs/tasks/telemetry/using-istio-dashboard/) to check which services are
|
||||
still sending plain text traffic to the service in "PERMISSIVE" mode and choose to lock
|
||||
down once the migration is done.
|
||||
|
||||
## Before you begin
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue