Authorization policy with waypoint proxies

Enforce Layer 7 authorization policies and request authentication in ambient mesh using waypoint proxies.

Without a waypoint installed, you can only use Layer 4 security policies. A waypoint gives you access to the full set of Layer 7 (L7) attributes in Istio’s AuthorizationPolicy, as well as request authentication.

Policy enforcement using waypoints

A basic L7 authorization policy looks like this example, which allows only GET requests from the curl service account to the productpage service:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-waypoint-policy
  namespace: default
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/curl
    to:
    - operation:
        methods: ["GET"]

Unlike policies targeted at ztunnel, waypoint policies use targetRefs instead of a selector and support L7 attributes.

Binding policy to all waypoints

The targetRefs field targets policy at specific services, and those policies are bound to the waypoints that those services are configured to use.

In some cases, you might want to apply a policy to every waypoint. A common example is a default DENY policy, where waypoints deny all traffic that is not explicitly allowed by another policy.

Target the GatewayClass resource to apply a policy to all waypoints:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: default-deny-waypoint
  namespace: istio-system
spec:
  targetRefs:
  - kind: GatewayClass
    group: gateway.networking.k8s.io
    name: istio-waypoint

For complete coverage, combine this policy with a default DENY policy for L4, enforced by ztunnel.

Restricting workloads to only accept traffic from waypoints

Ambient mesh routes traffic through waypoints when traffic is sent to a service. The ztunnel for a destination workload continues to accept connections from any endpoint. To ensure all traffic received by a workload comes from an in-mesh source, enable STRICT peer authentication.

To prevent waypoint policy enforcement from being bypassed, create a ztunnel policy that only allows connections from the workload’s waypoint¹. This example policy targets pods with the label app: productpage at the ztunnel layer by using a selector. The waypoint proxy presents the waypoint service account identity when forwarding traffic, so any connection that bypasses the waypoint and arrives with a different source identity is denied by ztunnel.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/waypoint

Exceptions

Some use cases require bypassing the waypoint. For example, an ingress gateway already enforces its own policies on inbound traffic before it reaches the workload, so routing that traffic through the waypoint again is redundant. Scraping Prometheus metrics also bypasses the waypoint, because routing through a waypoint adds unnecessary overhead.

The following policy extends the previous example with a second rule that allows the Prometheus service account in istio-system to scrape metrics directly on port 9090, while still requiring all other traffic to come through the waypoint:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/waypoint
  - from:
    - source:
        principals:
        - cluster.local/ns/istio-system/sa/prometheus
    to:
      - operation:
          ports: ["9090"]

Considerations for authorization policies

In ambient mesh, authorization policies are either targeted at ztunnel by using a workload selector, or attached to a waypoint by using targetRef. To attach a policy to a waypoint, the policy must have a targetRef that refers to the waypoint or to a Service that uses that waypoint.

The ztunnel cannot enforce L7 policies. If a policy with rules matching L7 attributes is targeted with a workload selector rather than attached with a targetRef, ztunnel enforces it as a DENY policy.

See the ztunnel policy guide for more information, including when to attach policies to waypoints for TCP-only use cases.

Policy enforcement for traffic splitting

In a waypoint, authorization policies are enforced pre-routing, based on the service that traffic was originally destined for. In a traffic-splitting setup where a parent service routes to child services, only the authorization policy applied to the parent service is enforced, even when all services use a waypoint.

For example, consider a reviews route that uses backendRefs to send traffic to the endpoints of the reviews-v1 service:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews
    port: 9080
  rules:
  - backendRefs:
    - name: reviews-v1
      port: 9080

If you have an authorization policy that targets reviews-v1, it is not enforced on traffic destined for reviews.

Apply the same authorization policy to all services in the traffic-splitting setup to maintain granular access control. For the reviews example, target both the parent (reviews) and child services (reviews-v1, reviews-v2, reviews-v3):

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: reviews-waypoint-policy
  namespace: default
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: reviews-v1
  - kind: Service
    group: ""
    name: reviews-v2
  - kind: Service
    group: ""
    name: reviews-v3
  - kind: Service
    group: ""
    name: reviews
...