Progressively rolling in strict mTLS
The MeshTLS policy allows you to gradually migrate services to mutual TLS without dropping a packet.
Prerequisites
- Completed quickstart to set up a zone control plane with demo application.
Basic setup
In order to be able to fully utilize MeshTLS policy you need to enable Mutual TLS (mTLS), and you can do it with builtin
CA backend by executing:
To make sure that traffic works in our examples let’s configure MeshTrafficPermission to allow all traffic:
Gradually bring another service into the mesh
Start a second demo app
First we start a new demo setup in another namespace called kuma-demo-migration
.
The below command installs the demo one more time in another namespace:
Below diagram shows which applications are inside the mesh and which are not. Purple links indicate that the communication is encrypted, gray ones are plaintext.
Enable port forwarding for both demo-apps
Open up both apps’ GUI and turn on auto incrementing.
Enable permissive mode on redis
We begin with preparing redis to start in permissive mode when deployed inside the mesh.
To enable permissive mode we define this MeshTLS
policy:
Migrate redis to mesh
Then we bring redis into the mesh by adding kuma.io/sidecar-injection=true label:
After this redis will be receiving plaintext traffic from non-meshed client.
You can go to the Kuma GUI, check the Stats
tab for the redis
Dataplane in the kuma-demo-migration
namespace, and you should see this metric increment :

The below diagram shows that the second redis was moved to be inside the mesh:
--- title: service graph when redis is inside the mesh --- flowchart LR subgraph meshed subgraph kuma-demo direction LR demo-app(demo-app :5000) redis(redis :6379) demo-app --> redis end subgraph kuma-demo-migration direction LR redis2(redis :6379) end end subgraph non-meshed subgraph kuma-demo-migration direction LR demo-app2(demo-app :5000) demo-app2 --> redis2 end end linkStyle 0 stroke:#d25585, stroke-width:2px; linkStyle 1 stroke:#555a5d, stroke-width:2px;
Migrate client to mesh
Next we do the same to the client so the traffic is encrypted:
After this is done, you’ll have to re-enable the port-forward, and then you can go to the Kuma GUI, check the Stats
tab for the redis
Dataplane in the kuma-demo-migration
namespace, and you should see this metric increment:

The below diagram shows that all services are now in the mesh:
--- title: service graph when both client and redis are inside the mesh --- flowchart LR subgraph meshed subgraph kuma-demo direction LR demo-app(demo-app :5000) redis(redis :6379) demo-app --> redis end subgraph kuma-demo-migration direction LR demo-app2(demo-app :5000) redis2(redis :6379) demo-app2 --> redis2 end end linkStyle 0,1 stroke:#d25585, stroke-width:2px;
Set strict mode on redis
Finally, to set strict mode you can either edit the policy or remove it (the default is taken from Mesh
object which is STRICT
).
Things to remember when migrating to strict TLS
If only encrypted traffic is sent to the destination, the difference between cluster.localhost_6379.upstream_cx_total
and inbound_10_42_0_13_6379.rbac.allowed
will not change after setting the workload to Strict
mode.
Next steps
With a couple of easy steps we were able to gradually bring a service into the mesh without dropping a packet and encrypting the traffic whenever it’s possible.
Read more about MeshTLS policy.