SPIRE-Enabled Workloads

Following are the three main methods used to enable application workloads to use SPIRE for mTLS zero trust:

Method 1

Place a non-SPIRE-enabled workload behind a SPIRE-aware front-end proxy, which leverages the well-understood service mesh pattern. In Kubernetes, it means that each pod has a sidecar container that performs attestation and consumes the SVID to perform mTLS on behalf of the pod's main workload. A significant example of this is Istio (v1.14 onward), which includes SPIRE functionality out of the box. In Istio's implementation, the Istio proxy sidecar, already an essential part of the Istio architecture, talks to a node agent by the Envoy Secret Discovery Service (SDS) protocol to retrieve the X.509 SVID on behalf of the pods's workload container (Figure 7). Proxies can now use this SVID to secure their mTLS communications with proxies belonging to other pods.

Figure 7: SPIFFE mTLS by Envoy proxies; workloads are unaware of SPIFFE IDs.

Method 2

Writing the workload to be natively SPIRE-aware is the purest and most committed approach. If you fully incorporate the use of SPIFFE in your code, it clearly becomes a necessary and irreplaceable component of the application, without which it cannot run; however, you can also realize the biggest benefits and take advantage of the flexibility of the SPIFFE ID URI format to share useful information between workloads. SPIRE libraries exist for Go, C and C++, Java, and Rust. The libraries make it easy to request an SVID from the local Workload API and then configure outbound network connections, or listening ports, to use the SVID for their TLS security purposes. The Go examples in the golang-spire-examples/example/ directory make this clear.

Method 3

Add the SPIFFE Helper utility to the workload. Given that an SVID is a completely normal TLS certificate in PEM format, along with a private key it can be used as a drop-in replacement for a certificate generated by any other means. You can use SVIDs to secure any application whose configuration allows a certificate and key to be provided by its administrator. The SPIFFE Helper utility is configured to interact with its local Workload API and to know the location of the TLS certificate and key used by the application that it's helping. When the Workload API pushes an updated SVID, the SPIFFE Helper writes that new SVID into the application's configured TLS certificate location and triggers the application to reload its certificates. For example, to use the SPIFFE Helper to SPIRE-enable a MySQL server, the Helper is configured with the certificate and key locations used by MySQL. Every TTL period, the Helper updates the contents of those locations with the SVID received via the Workload API, and then triggers the MySQL process to restart using the updated certificate and key.

SPIRE in Production

As soon as all communications between workloads in the SPIFFE domain are secured with valid short-lived SVIDs, anything that prevents the successful rotation of those SVIDs will bring the system grinding to a halt. This outcome was easy to show in the simple Kubernetes native workload example discussed earlier – simply scale the spire-server deployment to zero replicas. The application will carry on working as long as the existing SVIDs are valid, but as soon as they expire and cannot be refreshed, workloads will no longer be able to authenticate one another. For production use, making the SPIRE Server highly available is of paramount importance. To do so, the SPIRE Server should be scaled horizontally, and the back-end database should have multiple replicas.

Threat Model

Although SPIFFE allows for the network and application workloads to be fully untrusted, it does assume trust in the hardware on which the infrastructure runs – especially the hardware on which the SPIRE Server is running. Additionally, the attestation process requires SPIRE to trust the information presented to it by the attestation plugins. We looked at examples of Unix and Kubernetes attestation plugins, which require trust in the node operating systems and the Kubernetes cluster, respectively. For SPIFFE domains on the public cloud leveraging the native AWS and Google Cloud Platform (GCP) attestation plugins, it's assumed that Amazon and Google provide trustworthy information about their cloud environments.