In Kong Mesh running in universal mode with a MeshIdentity whose SPIFFE ID path template derives from the dataplane's kuma.io/workload label, the XDS authenticator in kuma-cp validates that label only when the dataplane token is bound to a workload. Workload binding is optional, so a dataplane presenting a tags-bound token can register with kuma.io/workload set to any value and obtain another workload's SPIFFE identity.
You are affected if all of the following hold:
- The control plane runs in universal mode.
- A MeshIdentity is configured whose SPIFFE ID path template derives from the workload label, including the default universal template /workload/{{ .Workload }}.
- Dataplanes authenticate with tokens that are not bound to a workload (tags-bound tokens, the common case, since workload binding is newer and optional).
You are not affected if:
- The control plane runs in Kubernetes mode. Its identity template is /ns/{{ .Namespace }}/sa/{{ .ServiceAccount }}, and the control plane derives those values from the pod's real identity rather than from a label the workload sets.
- Your MeshIdentity uses a SPIFFE template that does not reference the workload label.
- Every dataplane whose identity derives from the workload label already uses a workload-bound token.
Issue workload-bound dataplane tokens for every dataplane whose identity derives from the kuma.io/workload label. A workload-bound token constrains that label to the bound value, so a mismatched label is rejected at authentication.
Upgrade to Kong Mesh 2.13.10 or 2.14.2, whichever matches your release line. In patched versions a dataplane whose identity derives from the kuma.io/workload label requires a workload-bound token; an unbound tags-only token is rejected at XDS authentication. Kubernetes mode and universal templates that do not reference the workload label keep working with unbound tokens.