Kong Mesh 2.14 also introduces improvements to the mesh-scoped zone proxy deployment model. This makes it easier to configure and operate zone proxies for specific meshes, including Helm support for mesh zone proxy configuration.

For customers running many meshes or more complex multi-zone topologies, this gives finer-grained control over how zone proxy infrastructure is deployed and managed. For example:

meshes:
  - name: default
    ingress:
      enabled: true
      service:
        type: LoadBalancer
        port: 10001
      deployment:
        replicas: 2
    egress:
      enabled: true
      service:
        type: ClusterIP
        port: 10002
      deployment:
        replicas: 2

In Kong Mesh 2.14, we have added support for applying policies to mesh scoped zone proxies. This gives platform teams more control over traffic moving between zones and helps bring the same policy-driven operational model to cross-zone traffic that customers already use for workloads inside a mesh.  For example, being able to apply observability and permissions policies on a MeshExternalService, or gathering telemetry on all zone egress.

This release adds zone proxy support across policies:

• - `MeshTrafficPermission`
• - `MeshTimeout`
• - `MeshRateLimit`
• - `MeshFaultInjection`
• - `MeshCircuitBreaker`
• - `MeshHealthCheck`
• - `MeshProxyPatch`

As well as proxy observability:

• - `MeshMetric`
• - `MeshTrace`
• - `MeshAccessLog`

This is especially useful for larger multi-zone deployments where zone ingress and zone egress proxies are critical parts of the traffic path.

For example, to apply a MeshMetric policy to your egress proxies, you can use something like this:

type: MeshMetric
name: zone-egress-metrics
mesh: default
spec:
  targetRef:
    kind: Dataplane
    labels:
      kuma.io/listener-zoneegress: enabled
  default:
    backends:
      - type: Prometheus
        prometheus:
          port: 5670
          path: /metrics
          tls:
            mode: Disabled

Historically, customers had limited ways to apply fine-grained policy at the zone proxy layer. Zone egress traffic often represents many different upstream destinations flowing through the same proxy, so matching only on the proxy itself was too broad for many real-world use cases.

With Kong Mesh 2.14, policies can match on SNI for zone proxy traffic. This means teams can apply traffic controls based on the actual destination being reached, rather than applying the same behavior to every request passing through the zone proxy.

For example, you can inject failures for one external service reached through zone egress without affecting other external services:

type: MeshFaultInjection
name: zone-egress-fault-injection
mesh: default
spec:
  targetRef:
    kind: Dataplane
    labels:
      kuma.io/listener-zoneegress: enabled
  rules:
    - matches:
        - sni:
            type: Exact
            value: sni.extsvc.default.us-east-1.payments.443
      default:
        http:
          - abort:
              httpStatus: 503
              percentage: 50

The same matching model can also be used for rate limiting:

type: MeshRateLimit
name: zone-egress-rate-limit
mesh: default
spec:
  targetRef:
    kind: Dataplane
    labels:
      kuma.io/listener-zoneegress: enabled
  rules:
    - matches:
        - sni:
            type: Exact
            value: sni.extsvc.default.us-east-1.payments.443
      default:
        local:
          http:
            requestRate:
              num: 1
              interval: 1h
            onRateLimit:
              status: 429

This is a big step forward for customers operating shared zone egress infrastructure. Platform teams can now express policies that are specific to a destination, while still keeping the operational simplicity of centralized zone proxy deployments.

Kong Mesh 2.14 includes several observability improvements.

Control plane metrics can now be pushed through OpenTelemetry when an OTLP endpoint is configured, making it easier to integrate Kong Mesh operational metrics into existing observability pipelines.

We have also added and improved Grafana dashboards, including dashboards for zone proxies, so operators can more easily understand the health and behavior of their mesh infrastructure.

MeshMetric and MeshTrace have also been improved, including better workload identity information in metrics and traces.

For example, Mesh tracing, logging, and metrics can now be configured with a ***MeshOpenTelemetryBackend*** backend:

apiVersion: kuma.io/v1alpha1
kind: MeshOpenTelemetryBackend
metadata:
  name: main-collector
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  endpoint:
    address: otel-collector.observability
    port: 4317
  protocol: grpc
---
apiVersion: kuma.io/v1alpha1
kind: MeshMetric
metadata:
  name: all-metrics
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  default:
    backends:
      - type: OpenTelemetry
        openTelemetry:
          backendRef:
            kind: MeshOpenTelemetryBackend
     labels:
        kuma.io/display-name: main-collector
          refreshInterval: 30s
---
apiVersion: kuma.io/v1alpha1
kind: MeshTrace
metadata:
  name: all-traces
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  default:
    backends:
      - type: OpenTelemetry
        openTelemetry:
          backendRef:
            kind: MeshOpenTelemetryBackend
     labels:
        kuma.io/display-name: main-collector

    sampling:
      overall: 80
---
apiVersion: kuma.io/v1alpha1
kind: MeshAccessLog
metadata:
  name: all-access-logs
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  default:
    backends:
      - type: OpenTelemetry
        openTelemetry:
          backendRef:
            kind: MeshOpenTelemetryBackend
     labels:
        kuma.io/display-name: main-collector

This release tightens several defaults to improve the security posture of Kong Mesh deployments.

The Envoy admin API now uses a Unix domain socket by default instead of binding to localhost TCP. This reduces the risk of application containers in the same pod being able to access sensitive Envoy admin endpoints.

Localhost admin behavior has also been restricted so that only direct loopback requests are treated as admin requests, and CORS allowed domains are now empty by default unless explicitly configured.

These changes are designed to make the secure path the default path.

Kong Mesh 2.14 enables Kubernetes native sidecar containers by default for Kubernetes 1.29 and newer.

This improves startup and shutdown behavior by using Kubernetes' native sidecar lifecycle support, helping the sidecar start before application containers and remain available while the application shuts down.

Kong Mesh 2.14 also includes a number of smaller improvements that are useful for enterprise operations.

Customers can now generate zone tokens with an offline signing key. This is useful for environments where token issuance is part of a separate automation flow, or where operators want to avoid calling the control plane at token-generation time. For example:

kumactl generate zone-token \
  --zone zone-1 \
  --valid-for 24h \
  --scope ingress \
  --scope egress \
  --signing-key-path /keys/key.pem \
  --kid 1

The same offline signing flow is also available for user tokens:

kumactl generate user-token \
  --name john.doe@example.com \
  --group users \
  --valid-for 24h \
  --signing-key-path /keys/key.pem \
  --kid 1

Kong Mesh 2.14 expands the MeshIdentity provider model with extension providers. This allows MeshIdentity to integrate with external certificate authority systems such as AWS ACM Private CA, Vault, and cert-manager, while keeping the MeshIdentity API consistent for workloads.

For example, a MeshIdentity can use an ACM PCA-backed extension provider:

type: MeshIdentity
name: acm-pca-identity
mesh: default
spec:
  spiffeID:
    trustDomain: "{{ .Mesh }}.{{ .Zone }}.mesh.local"
    path: "/ns/{{ .Namespace }}/sa/{{ .ServiceAccount }}"
  provider:
    type: Extension
    extension:
      name: acmpca
      config:
        certificateAuthorityArn: arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/example
        region: us-east-1

Or a Vault-backed extension provider:

type: MeshIdentity
name: vault-identity
mesh: default
spec:
  spiffeID:
    trustDomain: "{{ .Mesh }}.{{ .Zone }}.mesh.local"
    path: "/ns/{{ .Namespace }}/sa/{{ .ServiceAccount }}"
  provider:
    type: Extension
    extension:
      name: vault
      config:
        address: https://vault.example.com
        mountPath: pki
        role: kong-mesh-workload

Or a cert-manager-backed extension provider:

type: MeshIdentity
name: cert-manager-identity
mesh: default
spec:
  spiffeID:
    trustDomain: "{{ .Mesh }}.{{ .Zone }}.mesh.local"
    path: "/ns/{{ .Namespace }}/sa/{{ .ServiceAccount }}"
  provider:
    type: Extension
    extension:
      name: certmanager
      config:
        issuerRef:
          name: mesh-issuer
          kind: ClusterIssuer

The exact `config` fields depend on the extension provider being used, but the MeshIdentity shape stays the same: select workloads, define their SPIFFE ID format, and choose the provider that issues their certificates.

Kong Mesh 2.14 also adds support for running without generated inbound tags. Historically, Kuma and Kong Mesh relied heavily on inbound tags such as `kuma.io/service `to identify service membership. That worked, but it also made MeshService generation dependent on tag data attached to individual inbound ports.

With 2.14, customers can opt in to label-based MeshService matching. This allows generated MeshServices to select dataplanes using workload labels instead of inbound tags, which is a cleaner model for Kubernetes and Universal environments and an important step toward the future 3.0 model.

This can be enabled through Helm:

experimental:
  inboundTagsDisabled: true

With this enabled, generated MeshServices use `dataplaneLabels` selectors:

type: MeshService
name: backend
mesh: default
spec:
  selector:
    dataplaneLabels:
      matchLabels:
        app: backend
        k8s.kuma.io/namespace: demo
  ports:
    - name: http
      port: 80
      targetPort: 8080
      appProtocol: http

This is especially useful for customers who want MeshService selection to follow platform labels, or who are preparing for a model where inbound tags are no longer the primary way to describe service membership.

Inbound Envoy listeners now use SO_REUSEPORT by default, improving connection distribution under load.

Kong Mesh 2.14 also includes improvements to delta xDS configuration through Helm and Kubernetes injection, plus additional xDS stability and size improvements. These changes help larger environments scale more smoothly as the number of workloads, services, and policies grows.

This is part of the Experimental deltaXds feature for 2.14, which will be the default in Kong Mesh 3.0:

helm upgrade --install kong-mesh kong-mesh/kong-mesh \
  --namespace kong-mesh-system \
  --set experimental.deltaXds=true

Before upgrading, customers should review the 2.14 upgrade notes carefully.

A few changes worth calling out:

• - The readiness reporter is now TCP-only on port 9902.
• - Envoy admin access now uses a Unix domain socket by default.
• - MeshAccessLog OpenTelemetry attribute keys are now validated.
• - Prometheus metrics changed from Summary to Histogram format.
• - MeshMultiZoneService names longer than 63 characters are deprecated.
• - CPU limits have been removed from default injected Kuma containers.
• - Externally managed RBAC manifests may need updates.

Want a deeper dive into a complete list of features, updates, and changes? Please refer to the [CHANGELOG](https://developer.konghq.com/mesh/changelog/)CHANGELOG.

Want to see Kong Mesh 2.14 in action? [Get a demo](https://konghq.com/products/kong-mesh/request-demo)Get a demo or [start using Kong Mesh](https://docs.konghq.com/mesh/2.11.x/introduction/install/)start using Kong Mesh today.

**1. What is a mesh-scoped zone proxy deployment model?**

A mesh-scoped zone proxy deployment model lets you deploy dedicated ingress and egress proxies for each mesh instance rather than sharing a single set across all meshes in a zone. This gives you independent traffic isolation, per-mesh policy enforcement, and cleaner failure domains. Kong Mesh 2.14 adds full Helm support for this model, so you can configure it declaratively alongside the rest of your GitOps workflow.

**2. How does SNI matching improve zone proxy traffic control?**

SNI matching lets zone proxies inspect the Server Name Indication field on incoming TLS connections and apply policies based on the destination service. Instead of blanket rules at the zone boundary, you get fine-grained control over which traffic policies apply to which services as traffic enters or exits a zone. This makes multi-mesh and multi-cluster policy enforcement significantly more precise.

**3. What policies can you apply to mesh-scoped zone proxies?**

Kong Mesh 2.14 supports ten policies on mesh-scoped zone proxies: MeshTrafficPermission, MeshTimeout, MeshRateLimit, MeshFaultInjection, MeshCircuitBreaker, MeshHealthCheck, MeshProxyPatch, MeshMetric, MeshTrace, and MeshAccessLog. These cover access control, resilience, observability, and traffic shaping at the zone proxy layer, giving you the same policy granularity at the mesh boundary that you already have at the sidecar level.

**4. How do Kubernetes native sidecars change sidecar management?**

Starting with Kong Mesh 2.14, Kubernetes native sidecars are enabled by default on clusters running Kubernetes 1.29 or later. Native sidecars use the Kubernetes init container lifecycle, which means the sidecar starts before your application container and stops after it. This eliminates common race conditions during pod startup and shutdown and removes the need for custom workarounds to manage sidecar ordering.

**5. What changed with observability in Kong Mesh 2.14?**

Control plane metrics now export via OTLP (OpenTelemetry Protocol), and the Grafana dashboards have been updated to use these improved metrics. A new MeshOpenTelemetryBackend resource gives you a declarative way to configure OpenTelemetry collection per mesh. Together, these changes consolidate observability into a single standards-based pipeline rather than relying on fragmented metric sources.

**6. How does Kong Mesh 2.14 strengthen security defaults?**

Three defaults changed. The Envoy admin API now communicates over a Unix domain socket instead of a TCP port, reducing the attack surface on each proxy. Localhost access to the admin API is restricted by default. And CORS headers ship empty by default, so cross-origin requests are blocked unless you explicitly configure an allow list. These changes enforce a stricter zero-trust baseline without requiring manual hardening.

**7. What are KDS offline signing tokens and when would you use them?**

KDS offline signing tokens let you pre-generate authentication tokens for zone control planes and users without requiring a live connection to the global control plane. This is useful for air-gapped deployments, disaster recovery scenarios, or any environment where the global control plane may be temporarily unreachable. You generate the tokens ahead of time and distribute them to zones or users as part of your provisioning workflow.