This policy uses new policy matching algorithm.
Do not combine with the deprecated TrafficPermission policy.
Mutual TLS has to be enabled to make MeshTrafficPermission work.
The MeshTrafficPermission policy provides access control within the Mesh.
It allows you to define granular rules about which services can communicate with each other.
When targetRef.kind: Dataplane selects a mesh-scoped zone proxy, MeshTrafficPermission can use spec.rules instead of spec.from.
The two forms are mutually exclusive.
Use targetRef.labels to select the proxy role and zone, and targetRef.sectionName to select the exact listener name from the zone proxy Dataplane.
For example, zone ingress can use 10001 and zone egress can use 10002.
On zone egress, destination matching happens through rules[].default.allow[] or deny[] entries.
Match the destination by SNI.
Since top level targetRef is empty it selects all proxies in the mesh.
TargetRef inside the from array selects proxies that have label kuma.io/zone: us-east.
These proxies will be subjected to the action from default.action.
The action is Allow. All requests from the zone us-east will be allowed on all proxies.
default: # 3 action: Allow
Copied!
TargetRef inside the from array selects proxies that have tags kuma.io/zone: us-east.
These proxies will be subjected to the action from default.action.
- targetRef: # 4 kind: MeshSubset tags: env: dev
Copied!
The action is Deny. All requests from the env dev will be denied on all proxies.
default: # 5 action: Deny
Copied!
Order of rules inside the from array matters.
Request from the proxy that has both kuma.io/zone: east and env: dev will be denied.
This is because the rule with Deny is later in the from array than any Allow rules.