Apply Layer 4 authorization policies

The Layer 4 (L4) features of Istio’s authorization policies are supported by ztunnel, and are available in ambient mode. Kubernetes network policies also continue to work if your cluster has a CNI plugin that supports them, and can be used to provide defense-in-depth.

The layering of ztunnel and waypoint proxies gives you a choice as to whether or not you want to enable Layer 7 (L7) processing for a given workload. To use L7 policies, and Istio’s traffic routing features, you can deploy a waypoint for your workloads. Because policy can now be enforced in two places, there are considerations that need to be understood.

Policy enforcement using ztunnel

The ztunnel proxy can perform authorization policy enforcement when a workload is enrolled in secure overlay mode. The enforcement point is the receiving (server-side) ztunnel proxy in the path of a connection.

A basic L4 authorization policy looks like this:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: allow-curl-to-httpbin
spec:
 selector:
   matchLabels:
     app: httpbin
 action: ALLOW
 rules:
 - from:
   - source:
       principals:
       - cluster.local/ns/ambient-demo/sa/curl

When there is no authorization policy provisioned, the default action is ALLOW. Once a policy is provisioned, pods targeted by the policy only permit traffic which is explicitly allowed. In the above example, pods with the label app: httpbin only permit traffic from sources with an identity principal of cluster.local/ns/ambient-demo/sa/curl. Traffic from all other sources will be denied.

Targeting policies

L4 policies are scoped by the namespace in which the policy object resides, and an optional selector in the spec. If the policy is in the Istio root namespace (traditionally istio-system), then it will target all namespaces. If it is in any other namespace, it will target only that namespace.

L7 policies in ambient mode are enforced by waypoints, which are configured with the Kubernetes Gateway API. They are attached using the targetRef field.

Allowed policy attributes

Authorization policy rules can contain source (from), operation (to), and condition (when) clauses.

This list of attributes determines whether a policy is considered L4-only:

Policies with Layer 7 conditions

The ztunnel cannot enforce L7 policies. If a policy with rules matching L7 attributes (i.e. those not listed in the table above) is targeted such that it will be enforced by a receiving ztunnel, it will fail safe by becoming a DENY policy.

Take the example above, and add a check for the HTTP method (an L7 attribute):

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: allow-curl-to-httpbin
spec:
 selector:
   matchLabels:
     app: httpbin
 action: ALLOW
 rules:
 - from:
   - source:
       principals:
       - cluster.local/ns/ambient-demo/sa/curl
   to:
   - operation:
       methods: ["GET"]

Even if the identity of the client pod is correct, the presence of a L7 attribute causes the ztunnel to deny the connection:

command terminated with exit code 56

Choosing enforcement points when waypoints are introduced

When a waypoint proxy is added to a workload, you now have two possible places where you can enforce L4 policy (L7 policy can only be enforced at the waypoint proxy).

When only using the secure overlay layer, traffic appears at the destination ztunnel with the identity of the source workload.

Waypoint proxies do not impersonate the identity of the source workload. Once you have introduced a waypoint to the traffic path, the destination ztunnel will see traffic with the waypoint’s identity, not the source identity.

This means that when you have a waypoint installed, the ideal place to enforce policy shifts. Even if you only wish to enforce policy against L4 attributes, if you are dependent on the source identity, you should attach your policy to your waypoint proxy. A second policy may be targeted at your workload to make its ztunnel enforce policies like “in-mesh traffic must come from my waypoint in order to reach my application”.

Peer authentication

Istio’s peer authentication policies, which configure mutual TLS (mTLS) modes, are supported by ztunnel.

The default policy for ambient mode is PERMISSIVE, which allows pods to accept both mTLS-encrypted traffic (from within the mesh) and plain text traffic (from without). Enabling STRICT mode means that pods will only accept mTLS-encrypted traffic.

As ztunnel and HBONE implies the use of mTLS, it is not possible to use the DISABLE mode in a policy. Such policies will be ignored.