L4 ztunnel-native egress: identity-based egress without a new proxy

Enable egress in ztunnel

The egress code path is gated by a Helm value on the ztunnel chart. Flip it on and ztunnel will register itself with the new solo-ztunnel-egress GatewayClass that istiod creates. This is a Helm-only install today; Gloo Operator support is not in 1.30.

helm upgrade ztunnel \
  oci://us-docker.pkg.dev/soloio-img/istio-helm/ztunnel \
  --version 1.30.0-beta.2-solo \
  --namespace istio-system \
  --reuse-values \
  --set enableEgressGateway=true

Install the ztunnel-egress chart with default-deny

The ztunnel-egress chart provisions the Gateway resource, binds it to the existing ztunnel DaemonSet, and ships a default-deny AuthorizationPolicy. Skip this and the Gateway accepts every ambient-captured source, which is the wrong starting point. The default for egressGateway.defaultDeny is false, so you have to set it explicitly.

helm upgrade -i ztunnel-egress \
  oci://us-docker.pkg.dev/soloio-img/istio-helm/ztunnel-egress \
  --version 1.30.0-beta.2-solo \
  --namespace istio-system \
  --set egressGateway.defaultDeny=true

The mechanism is subtle: the default-deny policy is an ALLOW AuthorizationPolicy with an empty rules: [] list. In Istio authz, an ALLOW policy that matches nothing denies everything through that target unless a more specific ALLOW policy permits it. That is what makes step 4 the gate that has to be opened for any source to use the egress at all.

If you prefer declarative resources, the next two YAML blocks are what the chart applies for you.

Declare an external host with a ServiceEntry

The ServiceEntry tells the mesh that httpbin.org exists, and the istio.io/use-waypoint labels send the traffic through the ztunnel-egress Gateway in istio-system. Without this binding the ServiceEntry exists but ztunnel won't pull it through the egress policy.

Allow the source at the Gateway layer

The default-deny in step 02 means no source can use the gateway. Open it for the source namespaces or service accounts that need outbound. This layer enforces who can use the egress gateway at all.

Allow the source at the ServiceEntry layer

The second layer attaches to the ServiceEntry and decides who can reach this specific destination. Both layers must allow the source. A common pattern is broad allows at the Gateway and tight per-destination allows at the ServiceEntry layer, so adding a new vendor host doesn't require touching the gateway policy.

Stop workloads bypassing the mesh with a NetworkPolicy

Mesh authz is a routing decision. A workload that opens a raw socket to an external IP simply skips the proxy and the policy with it. The fix is a stock Kubernetes NetworkPolicy that allows DNS and in-cluster traffic but refuses any other egress from workload pods. The podSelector excludes pods labelled as a gateway, so ztunnel itself is untouched and still functions.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: workload-egress
  namespace: bookinfo
spec:
  podSelector:
    matchExpressions:
      - key: gateway.networking.k8s.io/gateway-name
        operator: DoesNotExist
  policyTypes:
    - Egress
  egress:
    - ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP
    - to:
        - podSelector: {}

Capture every workload pod with ambient mode

Label every workload namespace istio.io/dataplane-mode=ambient. That is what triggers ztunnel's CNI redirect to grab outbound traffic from the pod's network namespace. Without the label, ztunnel never sees the pod and the policy story never starts.

Enforce the label at namespace creation with a Kyverno policy or a ValidatingAdmissionPolicy. If a developer can spin up a namespace without the label, they can spin up a workload that skips the mesh entirely.

Fence workload egress with a NetworkPolicy

This is the YAML in step 6. It allows DNS and in-cluster traffic and refuses everything else from workload pods. ztunnel itself is exempt because it runs in its own network namespace as a DaemonSet, not as a pod inside the workload namespace, so it can still egress freely while workloads cannot.

Without this layer, a workload can open a raw socket straight to an external IP and ztunnel's authz never fires. Mesh policy is a routing decision. NetworkPolicy is enforcement at L3/L4.

Catch unregistered destinations with ztunnel egressPolicies

The Gateway AuthorizationPolicy in step 4 only fires for traffic that ztunnel can match to a known destination in the service registry. If a workload dials an IP literal with no matching ServiceEntry, ztunnel cannot route it through the egress gateway and the AuthZ layer is never evaluated. The NetworkPolicy in layer 2 stops the packet eventually, but you also want a control inside ztunnel itself.

Set egressPolicies on the ztunnel Helm chart to deny any traffic ztunnel cannot match to a known destination. Two controls work in concert: egress policies handle unknown destinations, the Gateway AuthorizationPolicy handles known ones.

# values for the ztunnel chart
egressPolicies:
- matchCidrs:
  - 0.0.0.0/0
  - ::/0
  policy: Deny

Block hostNetwork: true pods at admission

A pod running with hostNetwork: true sits in the node's network namespace, not its own. CNI redirect does not apply. The NetworkPolicy in layer 2 does not apply either, because the policy selects on the pod's network identity and the pod is now using the node's. The workload has unimpeded access to whatever the node can reach.

Pod Security Admission at restricted or baseline level rejects hostNetwork pods. Apply it on every workload namespace by label, alongside the ambient label:

apiVersion: v1
kind: Namespace
metadata:
  name: bookinfo
  labels:
    istio.io/dataplane-mode: ambient
    pod-security.kubernetes.io/enforce: restricted

Drop pod-CIDR egress at the perimeter

Belt and braces. At the VPC or security-group level, drop outbound from the pod CIDR. Allow outbound only from the node IPs that ztunnel uses for egress SNAT. Even if every in-cluster control fails (admission policy disabled, NetworkPolicy deleted, namespace label dropped) the packet dies at the cloud network and never reaches the internet.

This is the layer auditors look for, because it does not depend on anything inside Kubernetes being correctly configured.