# How Kuma chooses the right policy to apply
At any single moment, there might be multiple policies (of the same type) that match a connection between sources
and destinations
Dataplane
s.
E.g., there might be a catch-all policy that sets the baseline for your organization
type: TrafficLog
mesh: default
name: catch-all-policy
sources:
- match:
service: '*'
destinations:
- match:
service: '*'
conf:
backend: logstash
2
3
4
5
6
7
8
9
10
11
Additionally, there might be a more focused use case-specific policy, e.g.
type: TrafficLog
mesh: default
name: web-to-backend-policy
sources:
- match:
service: web
cloud: aws
region: us
destinations:
- match:
service: backend
conf:
backend: splunk
2
3
4
5
6
7
8
9
10
11
12
13
What does Kuma
do when it encounters multiple matching policies ?
The answer depends on policy type:
- since
TrafficPermission
represents a grant of access given to a particular clientservice
,Kuma
conceptually "aggregates" all such grants by applying ALLTrafficPermission
policies that match a connection betweensources
anddestinations
Dataplane
s - for other policy types -
TrafficRoute
,TrafficLog
,HealthCheck
- conceptual "aggregation" would be too complex for users to always keep in mind; that is whyKuma
chooses and applies only "the most specific" matching policy in that case
Going back to 2 TrafficLog
policies described above:
- for connections between
web
andbackend
Dataplanes
Kuma
will choose and applyweb-to-backend-policy
policy as "the most specific" in that case - for connections between all other dataplanes
Kuma
will choose and applycatch-all-policy
policy as "the most specific" in that case
"The most specific" policy is defined according to the following rules:
a policy that matches a connection between 2
Dataplane
s by a greater number of tags is "more specific"E.g.,
web-to-backend-policy
policy matches a connection between 2Dataplane
s by 4 tags (3 tags onsources
and 1 tag ondestinations
), whilecatch-all-policy
matches only by 2 tags (1 tag onsources
and 1 tag ondestinations
)a policy that matches by the exact tag value is more specific than policy that matches by a
'*'
(wildcard) tag valueE.g.,
web-to-backend-policy
policy matchessources
byservice: web
, whilecatch-all-policy
matches byservice: *
if 2 policies match a connection between 2
Dataplane
s by the same number of tags, then the one with a greater total number of matches by the exact tag value is "more specific" than the otherif 2 policies match a connection between 2
Dataplane
s by the same number of tags, and the total number of matches by the exact tag value is the same for both policies, and the total number of matches by a'*'
(wildcard) tag value is the same for both policies, then a "more specific" policy is the one whose name comes first when ordered alphabetically
E.g.,
match by a greater number of tags
sources: - match: service: '*' cloud: aws region: us destinations: - match: service: '*'
1
2
3
4
5
6
7
8is "more specific" than
sources: - match: service: '*' destinations: - match: service: '*'
1
2
3
4
5
6match by the exact tag value
sources: - match: service: web destinations: - match: service: backend
1
2
3
4
5
6is "more specific" than a match by a
'*'
(wildcard)sources: - match: service: '*' destinations: - match: service: '*'
1
2
3
4
5
6match with a greater total number of matches by the exact tag value
sources: - match: service: web version: v1 destinations: - match: service: backend
1
2
3
4
5
6
7is "more specific" than
sources: - match: service: web version: '*' destinations: - match: service: backend
1
2
3
4
5
6
7when 2 matches are otherwise "equally specific"
name: policy-1 sources: - match: service: web version: v1 destinations: - match: service: backend
1
2
3
4
5
6
7
8policy-1
is considered "more specific" only due to the alphabetical order of names"policy-1"
and"policy-2"
name: policy-2 sources: - match: service: web destinations: - match: service: backend cloud: aws
1
2
3
4
5
6
7
8