Authorization policy with waypoint proxies
Without a waypoint installed, you can only use Layer 4 security policies. By adding a waypoint, you gain access to the the full set of Layer 7 attributes in Istio’s AuthorizationPolicy, as well as request authentication.
Policy enforcement using waypoints
A basic Layer 7 (L7) authorization policy looks like this:
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"]
There are two primary differences from a policy bound to ztunnel:
- The
targetRefs
field is used instead of a selector - Layer 7 attributes are supported
Restricting workloads to only accept traffic from waypoints
Where appropriate, ambient mesh will automatically route traffic through waypoints. By default, this is only when traffic is sent to a service.
The ztunnel for a destination workload will continue to accept connections from any
endpoint. (To ensure all traffic received by a workload comes from an in-mesh source,
enable STRICT
peer authentication.)
In order to ensure that waypoint policy enforcement cannot be bypassed, you can create a ztunnel policy to only allow connections from a workload’s waypoint1:
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
Common use cases where you may wish to allow a waypoint to be bypassed include accepting connections from a gateway, which can act as policy enforcement points themselves, and scraping Prometheus metrics from a pod, where the overhead of a waypoint is not useful. In these cases, add the appropriate rules to the ztunnel policy for the port you are serving metrics on:
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 can either be targeted (for ztunnel
enforcement) or attached (for waypoint enforcement). For an authorization
policy to be attached to a waypoint it must have a targetRef
which refers to
the waypoint, or a Service which 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
), such that it is enforced by a ztunnel, it will fail safe by
becoming a DENY
policy.
See the ztunnel policy guide for more information, including when to attach policies to waypoints for TCP-only use cases.
-
When at least one
ALLOW
rule exists for a destination, all other traffic is denied. ↩︎