Istio’s ambient mode revolutionizes how easy it is to add capabilities to your existing K8S workloads. By simply applying a Kubernetes label to a namespace, your workloads are granted Kubernetes identities, begin communicating over mTLS, start emitting telemetry, and gain support for robust Istio policy hooks, among other benefits – no sidecar injection or additional containers needed.
But what if you want more control and granularity over the identities your ambient workloads are granted? What if you want more granular identity attestation, rotation, and management than Kubernetes supports, but until now were intimidated by the costs and complexity of integrating a world-class solution like SPIRE with every workload, or even Istio itself?
If you’ve ever tried to integrate SPIRE and sidecar Istio in the past, the above paragraph might have sent a chill down your neck – but fear not! Ambient makes integrating SPIRE attestation and identity management into your Kubernetes clusters easier and better than ever – combining the operational benefits of Istio ambient mesh with the best-in-class workload identity and attestation of SPIRE.
Why Workload Identity Matters
If you’ve been following software security, zero-trust, NIST recommendations, and software supply chain security for any amount of time, you already know that workload identity is a cornerstone of all of these things.
Workload identity is what makes policy enforcement possible. Workload identity is what makes standards-compliant mTLS secure (or not). Workload identity is what makes software supply chain guarantees operationally useful.
A workload identity is like your identity – before we give you access to sensitive things, we need to know exactly who you are, and we need to be very sure that the identity you present is actually yours and that you aren’t presenting someone else’s ID.
- Is that your ID card, or did you steal it?
- Is that your IP address, or are you just spoofing?
- This is your service account, but how many other workloads share that same service account, and can we tell them apart if we have to, for the purposes of policy and audit?
Why SPIRE Matters To Istio
SPIRE is a CNCF project that implements workload attestation, identity issuance, and the SPIFFE open standard. It supports cloud-agnostic attestation of Kubernetes nodes and Kubernetes workloads using a pluggable attestation framework, as well as identity issuance and rotation.
SPIRE allows you to:
- Easily manage workload identity across clouds.
- Handle workload identity at a scale Kubernetes service accounts are not equipped for.
- Express multiple factors of workload attestation and complex attestation policy – “to get an identity for mTLS-secured communications, this pod must have a specific signature, and is only authorized to run on specific nodes, and must contain only an allowlist of processes”.
SPIRE supports far more robust and granular workload attestation policy enforcement (proving that an identity actually belongs to a workload) than Kubernetes is capable of, in addition to advanced multi-cluster topologies and cross-cloud brokering of identities. It is invaluable in large, multi-environment/multi-cluster Kubernetes deployments where zero-trust and regulatory compliance are paramount.
Istio is built on top of mTLS, which requires each workload that is communicating in the mesh to have a valid certificate – the Istio mesh (and mTLS) is only as strong as the assurances around the identities issued to workloads running inside of it. Combining Istio ambient and SPIRE makes for a powerful mix of strong workload identity guarantees, scalable identity management, and world-class workload-to-workload traffic encryption via Istio’s standards-compliant and regulatory-framework-friendly mTLS implementation.
For a deeper dive on workload identity and SPIRE specifically, we recommend this Solo blog on this topic: https://www.solo.io/blog/spire-attestable-workload-identity/
Bringing Ambient Benefits To SPIRE
While Istio has supported SPIRE integration with the sidecar dataplane mode for some time, Gloo Mesh’s support for SPIRE in the ambient dataplane mode is fundamentally different – when you enable SPIRE integration with Ambient, you:
- Register your workloads with SPIRE like you would with a normative SPIRE installation.
- Label your namespace for ambient dataplane mode like you would with a normative Istio Ambient installation.
Once you do this, every ambient workload will automatically have a SPIRE-managed identity, and will use that identity for mTLS – no need to mount sockets or volumes in every workload like with sidecars.
In this example we have 2 sample workloads deployed to a small cluster with SPIRE-enabled Istio ambient – when these workloads are added to the ambient mesh they are automatically getting leaf+chain identity certs from the SPIRE agent on the same node, which we can see by inspecting the local admin endpoint of the local ambient node proxy named ztunnel-hnv2x:
We can then decode one of these certs in PEM format, and verify that it is fact issued by SPIRE and not Istio. Note that since SPIRE is the issuing CA for these workload certificates, the contents are entirely dependent on the SPIRE configuration – your specific SPIRE installation may (and probably will) have different X509 values.
In the below example we can see the Organization on the cert is SPIRE, indicating Istio did not mint this workload cert – SPIRE did:
In ambient, the L4 node proxy is responsible for capturing and encrypting all pod-to-pod traffic, and thus is responsible for managing workload identities. In SPIRE-enabled ambient mode, the ambient node proxy obtains those identities directly from the SPIRE agent also running on the node, acting as a trusted delegate of SPIRE.
An important aspect of this approach is that the L4 node proxy doesn’t attest the workload – SPIRE does.
This allows the ambient dataplane to integrate with SPIRE’s delegation API as a trusted delegate, while still leveraging SPIRE’s existing best-in-class multi-factor node and workload attestation plugin frameworks directly, allowing the ambient dataplane to request workload certs as minted by SPIRE on the basis of those attestations. Both the ambient dataplane and SPIRE have to agree with each other, which effectively eliminates the potential for confused deputy problems.
As always, since this is ambient, the above model requires no sidecars or injection of additional containers into your workload pods to function – we are able to hook into the Kubernetes pod lifecycle and begin pod attestation and cert fetching and rotation via the SPIRE agent before your workload pods begin sending traffic through the mesh.
We strongly prefer this shared-responsibility model, because it allows us to lean on SPIRE to do what it’s best at (workload attestation and workload identity issuance) and allows Istio to focus on what it does best – securing workload traffic and enforcing network policy.
Wrap Up
As part of this effort we worked with the SPIRE project to enhance the SPIRE delegation capabilities to support this improved shared-responsibility model. Gloo Mesh’s ambient SPIRE integration uses this improved trusted delegation API, and we hope others will as well.
Huge shout-out to the SPIRE folks for collaborating! At Solo we believe workload identity is critical for zero-trust, and believe open, cross-cloud identity standards are the best way to achieve that.
We have customers who share that belief – in fact, they do more than believe it, they implement and deliver it in their environments, every day, meeting critical security and regulator requirements – and Gloo Mesh is here to help them do that. You can get in touch with our team to learn more about Gloo Mesh.
