In today’s dynamic cloud environments, long-lived credentials are a critical vulnerability, exposing organisations to security breaches and operational complexity. The definitive solution is a shift to modern workload identity, with short-lived SPIFFE credentials representing the gold standard for securing services with mutual TLS.

Yet, once the strategic decision to adopt SPIFFE is made, a new set of practical questions emerges. With several distinct methods available for an application to obtain its identity, the challenge shifts to choosing the right path. How do you select the best approach for a shiny new service versus a critical legacy application?

In this post, we’ll demystify these options. We’ll explore the various methods to SPIFFE-enable your workloads, discuss the key considerations for each, and show how Cofide through open source projects and the Connect platform makes the entire process more seamless and intuitive.

SPIFFE: a standard for workload identity

At its core, SPIFFE is like a universal passport system for software services. In today’s complex cloud environments, applications need a robust way to prove their identity to each other. Instead of using insecure, long-lived secrets (like API keys), SPIFFE provides applications access to cloud-agnostic short-lived credentials.

Here’s how it works:

• SVID (The Passport): Each workload is issued an SVID (SPIFFE Verifiable Identity Document). This is its passport, a cryptographically verifiable document such as an X.509 certificate or a JWT that it can present to other services.

• SPIFFE ID (The Passport Number): Inside the SVID is a unique SPIFFE ID, like spiffe://example.com/billing-api. This is the workload’s specific, unambiguous name.

• Trust Domain (The Issuing Country): All of this operates within a trust domain (e.g., “production” or “staging”). This is like the country that issues the passport, defining a boundary of trust with its own unique authority.

• Workload API (The Passport Office): Workloads are issued SVIDs using a local workload API endpoint.

This system allows services to verify identities and establish secure communication automatically, eliminating the need for risky, manually-managed credentials.

So the question is, how do applications that operate in a SPIFFE environment obtain an SVID and ensure it’s up-to-date and valid? Let’s consider the options.

Application-level integration

The most direct way for any application to obtain a short-lived SPIFFE credential is for it to make requests directly to the workload identity platform (e.g. via the SPIFFE Workload API using a provider like SPIRE, or Cofide’s Connect platform). This can be an intuitive means of onboarding a new or relatively simple application onto a workload identity plane, and provides complete control over the process from inside the workload itself. Developers can make fine-grained decisions about inter-workload authentication, and there’s no requirement for additional components like sidecars or proxies.

There are a number of libraries provided by the SPIFFE community and ecosystem, including Java, Rust and Python, to interface with the Workload API.

If you’re using Go, Cofide has an open source SDK cofide-sdk-go, which makes the process of enabling SPIFFE workload identity for web applications seamless by wrapping Go’s net/http. Under the hood, we build on the SPIFFE Go SDK, go-spiffe.

Here’s an example of how to use cofide-sdk-go to add support for SPIFFE to a web server:

package main

import (
	"net/http"
	cofide_http "github.com/cofide/cofide-sdk-go/http/client"
	"github.com/cofide/cofide-sdk-go/pkg/id"
)

func main() {
	...
	secureMux := http.NewServeMux()
	// cofide-sdk-go wraps Go's net/http and adds SPIFFE auth for mTLS
	// The SDK uses the Workload API to retrieve the SVID and keeps it up-to-date
	secureServer := cofide_http.NewServer(&http.Server{
		Handler: secureMux,
	}, 
	// Ensure clients present with a specific SVID
	cofide_http.WithSVIDMatch(id.Equals("ns", "production")),
	)
	secureMux.HandleFunc("/", handler(secureServer))
	...
}

With minimal code changes, you can onboard Go applications to the Connect identity platform and reap all the security benefits of SPIFFE - without the need for extra components like sidecars or proxies. See cofide-demos for more examples of how to use the Cofide Go SDK, including the corresponding client.

Enabling sidecar

Another common pattern, especially for workloads not easily updated is to run an enabling sidecar that interacts with the workload identity platform on behalf of the application. This removes any requirement to introduce SPIFFE-specific application code, and keeps the remit of SVID issuance strictly to a new separate component that is dedicated to this purpose. Depending on the requirements, sidecars can inject SVIDs to an expected filesystem location for native TLS, proxy ingress and egress to drop-in mutual TLS, and ingest networking information from upstream providers via protocols like xDS.

The SPIFFE community has spiffe-helper, a tool that can be used to retrieve and manage SVIDs on behalf of a workload. To make it seamless and easy to integrate with Kubernetes workloads, Cofide has recently open sourced spiffe-enable, a Kubernetes admission webhook that auto-injects the sidecar components into a workload. This is especially useful for non-SPIFFE native workloads.

It’s easy to get started. Install spiffe-enable using the Helm chart, and simply label the namespace and annotate the workload you wish to ‘SPIFFE enable’:

• Namespace label: spiffe.cofide.io/enabled: "true"
• Pod annotation: spiffe.cofide.io/inject: "helper"

spiffe-enable can also be configured to inject a debug dashboard (to see the the SVID and the bundle), as well as a lightweight network proxy (Envoy) that works with the Connect Agent for service discovery, to help you securely connect with services across trust zones, including those in a service mesh.

Service mesh proxy

Service meshes, like Istio, have seen considerable adoption largely because they have helped to solve a critical security problem: automated encrypted communication (mTLS) at scale. To achieve this, Istio acts as its own CA (Certificate Authority), automatically issuing and managing the identities (X.509 certificates) that workloads need to trust each other. This has made large-scale service security practical for the first time.

However, Istio’s built-in identity system is self-contained, at least out-of-the-box. Fortunately, Istio is SPIFFE-compliant and so it can be integrated with a workload identity provider, such as SPIRE and Cofide’s Connect platform. Connect enables an Istio service mesh to securely federate with workloads in other trust zones (domains), building on the foundation of SPIFFE identity and trust.

Many paths, one solution

Using the foundations of SPIFFE and the Workload API, there are a variety of methods by which applications can obtain workload identity. At Cofide, we believe that supporting optionality is key. Across different cloud environments and providers, with a variety of workloads, our partners need to integrate SPIFFE with applications at differing levels of maturity. Whether it’s through direct integration or a sidecar proxy, the variety of methods we’ve discussed are all designed to meet workloads where they are. The journey to onboard needs to be low friction and seamless - we firmly believe the secure option must be the easy option. That’s why we’re focused on solving the fundamental problems associated with workload identity, while ensuring the methods to use the solution can support many use cases across the cloud native ecosystem.

Get started

We’re just getting started, and we invite you to join the journey. Explore our open source projects or see how the Connect platform can expedite your adoption of standards-based workload identity with SPIFFE today.