You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With MeshService policy matching (#10152) and policy on namespace (#10148) we're getting a good story for producer/consumer policies and how to "attach a policy to a service"
The choice was made for spec.to[].targetRef.kind: MeshService this goes a little against how MeshHTTPRoute matches which was decided in MADR-028.
The strong argument for going with top level targetRef in MADR-28 was matching dataplanes that don't have the route. In this case it's simple enough we just ignore it.
This current implementation has made things a little tricky because policy matching is convoluted where the top level MeshHTTPRoute gets converted to a "fake to":
Allow spec.to[].targetRef.kind: Mesh*Route working like MeshService (If the service has this route then we apply the matcher on it). It's also great because we can add validation like (disallow TCP parameters on MeshHTTPRoute matches).
Deprecate MeshService and MeshHTTPRoute as a toplevel targetRef (top level targetRef should identify entire proxies) 1
Make topLevel targetRef optional (in practice people will most often use targetRef: kind: Mesh). Having it optional creates less confusion to users about "where they should match stuff".
benefits
top level targetRef is something most people can ignore so this makes policies easier to use (this was already discussed in MADR-005 but I think experience has changed our mind).
topLevel targetRef is complex (it depends on whether the policy is created on the zone, in the namespace of the service, another one...)
The policy matching algorithm and rules api becomes simpler and there are no indirections anymore top level targetRef identifies proxies that are matched and then to and from identify parts of the config (namely: inbounds, outbounds and routes).
Mesh, MeshSubset and MeshGateway would be the only topLevel targetRef allowed. We talked about remove MeshSubset but that's a parallel discussion. MeshGateway can identify a specific listener but in practice Each Gateway listener is very similar to being its own proxy so I'm not concerned here. ↩
The text was updated successfully, but these errors were encountered:
Description
With
MeshService
policy matching (#10152) and policy on namespace (#10148) we're getting a good story for producer/consumer policies and how to "attach a policy to a service"The choice was made for
spec.to[].targetRef.kind: MeshService
this goes a little against how MeshHTTPRoute matches which was decided in MADR-028.The strong argument for going with top level targetRef in MADR-28 was matching dataplanes that don't have the route. In this case it's simple enough we just ignore it.
This current implementation has made things a little tricky because policy matching is convoluted where the top level MeshHTTPRoute gets converted to a "fake
to
":kuma/pkg/plugins/policies/core/rules/rules.go
Lines 346 to 401 in 55fa983
suggested changes
spec.to[].targetRef.kind: Mesh*Route
working likeMeshService
(If the service has this route then we apply the matcher on it). It's also great because we can add validation like (disallow TCP parameters on MeshHTTPRoute matches).MeshService
andMeshHTTPRoute
as a toplevel targetRef (top level targetRef should identify entire proxies) 1targetRef: kind: Mesh
). Having it optional creates less confusion to users about "where they should match stuff".benefits
to
andfrom
identify parts of the config (namely: inbounds, outbounds and routes).open questions
xref
examples
A producer attached policy (all consumers everywhere use this):
A consumer policy:
A producer policy applying to just some proxies:
(the consumer ones work the same).
Footnotes
Mesh, MeshSubset and MeshGateway would be the only topLevel targetRef allowed. We talked about remove MeshSubset but that's a parallel discussion.
MeshGateway
can identify a specific listener but in practice Each Gateway listener is very similar to being its own proxy so I'm not concerned here. ↩The text was updated successfully, but these errors were encountered: