Security

Security

Ambient mesh transparently adds mutual TLS (mTLS) encryption between all the enrolled workloads. You can also configure policies for authentication and authorization, to mitigate both insider and external threats against your data, endpoints, communication, and platform.

Istio’s security architecture

Each workload running in a service mesh has an identity, created based on its namespace and service account.

The Istio control plane provides a Certificate Authority (CA) for key and certificate management. Each proxy server requests certificates as appropriate, which are used to mutually verify connections between them.

ztunnel proxies operate on behalf of all the workloads on a given node, and thus request and receive multiple certificates. Gateways and waypoints each have their own identities.

Authentication

Ambient mesh offers two kinds of authentication:

  • peer authentication, which allows a destination to trust the identity of a source (and vice versa)
  • request authentication, which allow you to validate a JSON Web Token (JWT) on a L7 request

Peer identities are validated by all the proxies in an ambient mesh. By default, services in the mesh will accept non-mTLS connections, but this can be overridden.

Request authentication features are supported when a workload is enrolled in the waypoint layer.

Authorization

Authorization policy allows access control for traffic in an ambient mesh. Because all connections are authenticated, you can create policies with rules that refer to the caller’s identity.

Authorization policy for Layer 4 can be applied at the secure overlay layer. To use Layer 7 features, a waypoint proxy must be deployed.

The two different types of authorization policy

In order to understand how authorization policy works in ambient mesh, it is helpful to work backwards. Consider a standard workload with no waypoint deployed. The only place where policy can be enforced is the ztunnel at the server end. By design, ztunnels are not L7-aware, so only L4 policy can be enforced.

Authorization policy with no waypoints deployed: one possible enforcement point

Authorization policy with no waypoints deployed: one possible enforcement point

When you introduce a waypoint, you now have two places where policy can be enforced for services which are enrolled in it:

Authorization policy with a waypoint proxy: two possible enforcement points.

Authorization policy with a waypoint proxy: two possible enforcement points.

These conceptual diagrams ignore the fact that there can be multiple instances of a workload, on more than one node, and there can be multiple instances of a waypoint. Therefore, we must write our policy to describe where we want it to be applied: that is, on calls to which service, or which workload.

Then, the policies must be bound to the proxies that can enforce them:

Policies are described relating to services or workloads, and bound to waypoints or ztunnels.

Policies are described relating to services or workloads, and bound to waypoints or ztunnels.

Learn more about each type of policy:

How certificates are issued

In ambient mesh, the secure overlay layer handles mTLS encryption. For this, ztunnel has to request, and be issued, certificates for every workload that runs on its host.

ztunnel creates a key and requests a certificate

When a workload starts on a node, the CNI agent running on the node will notify the ztunnel. The ztunnel connects to the Istio control plane, stating that it is representing that workload, and requesting the attestation and signing of a certificate.

istiod verifies the request

Istiod checks that the workload is running on the node in question. ztunnel is authorized to request certificates for any Service Accounts of pods running on the same node. Similar to kubelet node authorization, this explicitly does not allow requesting arbitrary certificates. This ensures these privileges are node-local only. For more information, refer to the Istio security model documentation.

A certificate is issued

The control plane signs the request and returns the certificate to the ztunnel.