MeshTrafficPermission
This policy uses new policy matching algorithm. Do not combine with TrafficPermission.
TargetRef support matrix
TargetRef type | top level | to | from |
---|---|---|---|
Mesh | ✅ | ❌ | ✅ |
MeshSubset | ✅ | ❌ | ✅ |
MeshService | ✅ | ❌ | ✅ |
MeshServiceSubset | ✅ | ❌ | ✅ |
If you don’t understand this table you should read matching docs.
Configuration
Action
Kuma allows configuring one of 3 actions for a group of service’s clients:
Allow
- allows incoming requests matching the fromtargetRef
.Deny
- denies incoming requests matching the fromtargetRef
AllowWithShadowDeny
- same asAllow
but will log as if request is denied, this is useful for rolling new restrictive policies without breaking things.
Examples
Service ‘payments’ allows requests from ‘orders’
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
namespace: kuma-system
name: allow-orders
spec:
targetRef: # 1
kind: MeshService
name: payments
from:
- targetRef: # 2
kind: MeshService
name: orders
default: # 3
action: Allow
Explanation
-
Top level
targetRef
selects data plane proxies that implementpayments
service. MeshTrafficPermissionallow-orders
will be configured on these proxies.targetRef: # 1 kind: MeshService name: payments
-
TargetRef
inside thefrom
array selects proxies that implementorder
service. These proxies will be subjected to the action fromdefault.action
.- targetRef: # 2 kind: MeshService name: orders
-
The action is
Allow
. All requests from serviceorders
will be allowed on servicepayments
.default: # 3 action: Allow
Deny all
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
namespace: kuma-system
name: deny-all
spec:
targetRef: # 1
kind: Mesh
from:
- targetRef: # 2
kind: Mesh
default: # 3
action: Deny
Explanation
-
Top level
targetRef
selects all proxies in the mesh.targetRef: # 1 kind: Mesh
-
TargetRef
inside thefrom
array selects all clients.- targetRef: # 2 kind: Mesh
-
The action is
Deny
. All requests from all services will be denied on all proxies in thedefault
mesh.default: # 3 action: Deny
Allow requests from zone ‘us-east’, deny requests from ‘dev’ environment
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
namespace: kuma-system
name: example-with-tags
spec:
targetRef: # 1
kind: Mesh
from:
- targetRef: # 2
kind: MeshSubset
tags:
kuma.io/zone: us-east
default: # 3
action: Allow
- targetRef: # 4
kind: MeshSubset
tags:
env: dev
default: # 5
action: Deny
Apply the configuration with kubectl apply -f [..]
.
Explanation
-
Top level
targetRef
selects all proxies in the mesh.targetRef: # 1 kind: Mesh
-
TargetRef
inside thefrom
array selects proxies that have labelkuma.io/zone: us-east
. These proxies will be subjected to the action fromdefault.action
.- targetRef: # 2 kind: MeshSubset tags: kuma.io/zone: us-east
-
The action is
Allow
. All requests from the zoneus-east
will be allowed on all proxies.default: # 3 action: Allow
-
TargetRef
inside thefrom
array selects proxies that have tagskuma.io/zone: us-east
. These proxies will be subjected to the action fromdefault.action
.- targetRef: # 4 kind: MeshSubset tags: env: dev
-
The action is
Deny
. All requests from the envdev
will be denied on all proxies.default: # 5 action: Deny
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.