docs(MADR): policy on namespace

[lobkovilya]

Checklist prior to review

• [X] Link to relevant issue as well as docs and UI issues -- Fix https://github.com/kumahq/kuma/issues/7269
• [X] This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS --
• [X] Tests (Unit test, E2E tests, manual test on universal and k8s) --
  • Don't forget ci/ labels to run additional/fewer tests
• [X] Do you need to update UPGRADE.md? --
• [X] Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label) --

[lobkovilya]

While thinking about: https://github.com/kumahq/kuma/issues/10247 and thinking about syncing to zones with producer/consumer policies it struck me that you could have multiple to entries with different kinds (one could be producer, the other consumer). What would be the syncing behaviour in this case?

The new validation rules are going to limit what policies you can create. If top-level targetRef doesn't specify kuma.io/zone and k8s.kuma.io/namespace then each item in to[] has to specify both kuma.io/zone and k8s.kuma.io/namespace. That's kind of a downside we're having with new design – consumer policies must have kuma.io/zone and k8s.kuma.io/namespace tags in top-level targetRef, i.e Frontend Owner wants to change how frontend communicates with others:

metadata:
  namespace: frontend-ns
  labels:
    kuma.io/origin: zone
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: i-have-to-know-the-name-of-my-zone
      k8s.kuma.io/namespace: frontend-ns
  to:
    - targetRef:
        kind: Mesh
      default: {}