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.
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.
When you introduce a waypoint, you now have two places where policy can be enforced for services which are enrolled in it:
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:
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.