Security and policy when migrating to ambient mesh

Istio’s security features are its primary value proposition for many users. Key amongst them is the automatic use of mutual TLS (mTLS) to validate and encrypt communication between workloads. The two-layer design of ambient mesh means that this is something you should very rarely have to consider. All traffic between two ztunnels, or a ztunnel and waypoint¹, uses HBONE — Istio’s mTLS over HTTP/2 tunnel protocol. You no longer have to worry about server-send-first protocols, protocol sniffing, or reserved ports.

What you do need to worry about is changes to how you handle authorization, given the fact that these can now be applied to each layer individually.

Authorization

The design of ambient mesh was driven by the fact that the most common use case that people turn to service mesh for is mTLS. In a practical sense, that means the deployment of cryptographic identities to each workload in a cluster, and the enforcement of encryption on the wire based on those identities.

These identities can also be used to enforce policy: only workload A can talk to workload B. This is a Layer 4 construct, and can be enforced by the ztunnel proxies that power the “secure overlay” in ambient mesh.

In order to unlock Istio’s full set of Layer 7 policies, such as “workload A can issue HTTP PUT requests to workload B, but not HTTP GET requests”, you will need to deploy waypoints. However, our experience tells us:

• Layer 4 features alone are enough for a large percentage of service mesh adopters
• Users who need Layer 7 features do not need them for all workloads

Thus, ambient mesh allows you to enforce policy in two different places: the ztunnel (for Layer 4 policy only) and the waypoint (for Layer 4 and Layer 7 policy).

ztunnel-enforced

A ztunnel-enforced authorization policy is the same as a sidecar mode policy, with the necessary exception that it can only process Layer 4 attributes. It is applied server-side by the ztunnel on the same node as the destination workload:

This is the same targeting method as selecting a server-side sidecar to apply a policy to, and thus at first glance you might believe you can take a sidecar mode policy and use it in ambient mode. This is true, but only if the policy rules only use allowed Layer 4 attributes. For example, you can validate identity, namespace, IP and port, as those attributes are all visible to ztunnel. Layer 7 attributes, like request type and host header, are not visible.

Any policy that uses an invalid attribute will be changed to be more restrictive than specified, out of an abundance of caution. The status field on the policy will be updated to make this clear.

If you are validating client identity with an authorization policy, be aware that waypoints do not spoof client identity. That means a ztunnel will see waypoint-routed traffic with the identity of the waypoint, not of the initiating client. If this is important, you should apply such policies at your waypoint, instead of at the ztunnel.

Waypoint-enforced

In order to perform policy actions based on a Layer 7 attribute, e.g. to allow or deny traffic based on an HTTP header, traffic must traverse a waypoint proxy.

The same AuthorizationPolicy object is used to define policies for Layer 4 and Layer 7. When targeting services instead of workloads, it uses Gateway API semantics.

To take a sidecar mode policy and use it for a waypoint in ambient mode, you need to add a targetRefs section. This will generally target one or more Services, but you may find it more convenient to target the waypoint directly (using kind: Gateway) and the policy will be applied to all traffic that traverses that waypoint.

Preventing authorization bypass

If you define a workload’s policy at a waypoint, you must ensure that all traffic to that workload traverses that waypoint. This is especially important while executing a migration, as upstream Istio does not have waypoint-aware sidecars.

If you are using a waypoint for a service, and enforcing policy at that waypoint, you may want a Layer 4 authorization policy that rejects all traffic that does not come from that waypoint. You may also want to specifically allow traffic from other trusted sources, such as an ingress gateway or a Prometheus scraper.

Default DENY

It is common to want to create a policy posture that denies all traffic, and then allows traffic piece-by-piece afterwards. You can easily do this at Layer 4, and may have such a rule in your Istio environment already. However, ambient mode gives you an easy bypass of that rule by delivering traffic to a service’s waypoint, which is explicitly allowed by the rules created above.

To solve this, you can create a second rule which applies to all waypoints. With these two rules, you have applied a complete default DENY posture.

Using the migration helper

Solo’s migration tool will attempt to update sidecar mode authentication policies by making the following changes:

• Policies that will require the use of a waypoint recommend such a deployment
• Policies with label targets that match an existing service will have their rules copied to a new policy that targets the service, and so will be attached to the new waypoint

You should carefully consider the newly created policies before removing or changing any old policies.

Authentication

There are two types of authentication policy in Istio; peer authentication (for workloads) and request authentication (for traffic).

Peer authentication

Similar to sidecar mode, you can configure whether a workload allows unencrypted traffic using a PeerAuthentication policy. In the default PERMISSIVE mode, pods in the ambient mesh will accept unencrypted traffic. If you enable STRICT mode, then they will only allow mTLS traffic. There is no DISABLE option, as all ambient traffic is encrypted.

Few people will need to change their peer authentication policies as a result of migration.

Request authentication

Because RequestAuthentication API operates at Layer 7, any policies must be changed to attach to a waypoint using the Gateway API semantics (targetRefs).