General notes about Kuma policies

You may have already noticed that most Kuma policies have very similar structure, namely

  1. sources:
  2. - match:
  3.     service: ... # unique name OR '*'
  4.     ... # (optionally) other tags
  6. destinations:
  7. - match:
  8.     service: ... # unique name OR '*'
  9.     ... # (optionally) other tags
  11. conf:
  12.   ... # policy-specific configuration

where

  • sources - a list of selectors to match those Dataplanes where network traffic originates
  • destinations - a list of selectors to match those Dataplanes where network traffic destined at
  • conf - configuration to apply to network traffic between sources and destinations

To keep configuration model simple and consistent, Kuma assumes that every Dataplane represents a service, even if it’s a cron job that doesn’t normally handle incoming traffic.

Consequently, service tag is mandatory for sources and destinations selectors.

If you need your policy to apply to every connection between Dataplanes, or simply don’t know yet what is the right scope for that policy, you can always use '*' (wildcard) instead if the exact value.

E.g., the following policy will apply to network traffic between all Dataplanes

  1. sources:
  2. - match:
  3.     service: '*'
  5. destinations:
  6. - match:
  7.     service: '*'
  9. conf:
  10.   ...

In contrast, the next policy will apply only to network traffic between Dataplanes that represent web and backend services:

  1. sources:
  2. - match:
  3.     service: web
  5. destinations:
  6. - match:
  7.     service: backend
  9. conf:
  10.   ...

Finally, you can further limit the scope of a policy by including additional tags into sources and destinations selectors:

  1. sources:
  2. - match:
  3.     service: web
  4.     cloud:   aws
  5.     region:  us
  7. destinations:
  8. - match:
  9.     service: backend
  10.     version: v2      # notice that not all policies support arbitrary tags in `destinations` selectors
  12. conf:
  13.   ...

While all policies support arbitrary tags in sources selectors, it’s not generally the case for destinations selectors.

E.g., policies that get appied on the client side of a connection between 2 Dataplanes - such as TrafficRoute, TrafficLog, HealthCheck - only support service tag in destinations selectors.

In some cases there is a fundamental technical cause for that (e.g., TrafficRoute), in other cases it’s a simplification of the initial implementation (e.g., TrafficLog and HealthCheck).

Please let us know if such constraints become critical to your use case.