What are SPIFFE and SPIRE?

SPIFFE and SPIRE are a pair of open source projects for identity management in dynamic and varied computing environments.

SPIFFE (pronounced “spiffy”) stands for Secure Production Identity Framework for Everyone. It establishes a structure for identities, along with a way to cryptographically verify IDs and deem them trustworthy.

SPIRE is short for SPIFFE Runtime Environment. SPIRE is the reference implementation for SPIFFE.

Together, SPIFFE and SPIRE define a way to enforce a zero trust architecture in complex hybrid cloud environments. The SPIFFE/SPIRE framework solves many security problems, including:

• Enhancing the security of cloud-native applications in Kubernetes environments.
• Improving authentication in edge computing locations.
• Managing identities for AI agents and other nonhuman workloads. 

Both SPIFFE and SPIRE are graduated projects of the Cloud Native Computing Foundation (CNCF). Red Hat offers an enterprise-ready SPIFFE/SPIRE implementation, the Red Hat® zero trust workload identity manager, as a Red Hat OpenShift® operator in tech preview.

SPIFFE supporters sometimes describe it as a solution to the “bottom turtle problem.” Authors from the SPIFFE project even used the turtle metaphor as a book title about the technology. 

So what’s the bottom turtle problem?

In an old story, a character insists that the world rests on the back of a giant turtle. Challenged to explain what the turtle is standing on, the character says it stands on the back of another, even larger turtle. And what does that turtle stand on? “It’s turtles all the way down!”

Computer security has a similar bottom turtle problem. Secrets, such as passwords and application programming interface (API) keys, help different platforms and services know they can trust one another. Keeping those secrets safe requires additional layers of security, like private encryption keys and a secrets repository to store the keys. How do you protect the secrets repository? With more secrets. Pretty soon, it’s secrets all the way down.

The SPIFFE standard and SPIRE implementation aim to establish the “bottom turtle,” providing a base level of trust for all interactions in a system.

SPIFFE and SPIRE are a way to improve IT security. Together they form a framework for making sure access is granted only to interactions with verified identities. As an analogy, you might think of SPIFFE and SPIRE as multifactor authentication (MFA) for workloads.

SPIFFE: The framework

SPIFFE sets specifications for issuing and managing cryptographic identities for services across different environments. The core of this standard is the SPIFFE Verifiable Identity Document (SVID), a short-lived credential that serves as a workload's identity.

In a zero trust architecture, where no component is trusted by default, SPIFFE allows for workload authentication without relying on secrets. When a workload needs to interact with another service, it can present its SVID, which is typically in the form of an X.509 certificate or a JSON Web Token (JWT).

Other workloads can then verify the SVID locally, enabling trusted, peer-to-peer authentication without the need to contact a central authority for every transaction. This streamlined process simplifies and protects service communication by maintaining trust through a verifiable, standardized identity.

SPIRE: The runtime environment

SPIRE describes a way to implement the SPIFFE standard. It defines a process to set up APIs that establish trust between workloads (applications or agents making a request) and nodes (servers or machines).

SPIRE takes attestation into consideration for both the workload and node. This means it makes sure both the application and the resource are what they say they are before issuing a signing certificate.

A SPIRE server acts as a signing authority for identities within its SPIFFE domain. It also keeps track of workload identities in a registry. 

In addition to the SPIRE server, SPIRE agents run on each node where a workload is running. These agents keep a cache of SVIDs and attest to the identity of workloads. SVID verification can happen locally, using kernel-level introspection. In other words, the workload doesn’t need to call an outside service to check if some action is authorized.

SPIRE supports federation, through which different systems exchange trust bundles that contain the public keys and certifications needed to validate them. 

SPIFFE and SPIRE can help with authentication in distributed multicloud environments. Some common use cases include:

Authentication in hybrid cloud environments

In hybrid and multicloud environments, applications can span multiple cloud providers and administrative boundaries. This makes it more complex when you’re trying to implement trusted communication across these domains. 

With SPIFFE federation, your SPIRE servers running in different places can exchange public keys and certificates via trust bundles, which is a format for a collection of public keys in use by a given SPIFFE issuing authority. This helps applications establish trust, even across different cloud providers or administrative boundaries, without private keys or complex network configurations.

Identity management in Kubernetes and KubeVirt

Kubernetes environments typically involve many small workloads running in isolated containers that have to cooperate with one another. SPIFFE and SPIRE can improve security in Kubernetes environments by providing authentication for containerized applications wherever they’re running on the network. This enhanced security also works for virtual machines running on solutions based on KubeVirt, such as Red Hat OpenShift Virtualization. This helps facilitate granular access control, a key principle of zero trust architecture.

Workflows for AI agents

AI agents―which take instructions and then go interact with some other system to achieve a goal―are becoming more common. But putting AI agents to work isn’t easy when it comes to sensitive information. Granting access to an AI agent requires strong, verifiable identities for machine workloads, something that becomes even more complicated across hybrid cloud platforms. SPIFFE and SPIRE can provide part of the solution with verifiable, short-term credentials that let AI services access sensitive data in a controlled way.

Service mesh trust

A service mesh is a layer that handles communication between services, especially in containerized applications. A SPIFFE and SPIRE implementation can add integrated security management to a service mesh, allowing service meshes to rely on cryptographically verifiable identities. This level of trust simplifies interoperability between systems. It also helps with policy enforcement, both inside and outside the service mesh.

Edge computing security

Because SPIFFE and SPIRE extend the identity control plane to local environments, they can be a good fit for edge computing. Cryptographically verifiable SVIDs mean you can implement strong authentication anywhere on your network, even for far-flung distributed edge services.

Read about confidential computing

Running modern applications in the cloud requires some level of automation. A popular choice for this is Kubernetes, an open source platform for deploying, managing, and scaling applications in containers. Kubernetes is the foundation for Red Hat OpenShift.

With SPIFFE and SPIRE as your identity control plane—the “bottom turtle” we mentioned earlier—you can work with verifiable identities across Kubernetes. Here are 3 key things to know about SPIFFE and SPIRE in Kubernetes:

1. SPIRE is the framework for implementing SPIFFE. You’ll need to deploy SPIRE components within your Kubernetes cluster. These include the SPIRE server, which manages identities and signing, and SPIRE agents, one of which needs to run on each Kubernetes node. These components create your foundational identity infrastructure and prepare your cluster to cryptographically verify identities. Red Hat zero trust workload identity manager can facilitate this in Red Hat OpenShift environments.
2. SPIRE agents perform both node and workload attestation. Agents can inspect an application's characteristics―such as its Kubernetes namespace, service account, or container image―to verify the application’s legitimacy.
3. Once attested, applications access the local SPIFFE workload API exposed by the SPIRE agent to get their unique, short-lived SVIDs. These SVIDs help establish mutual transport layer security (mTLS) connections, ensuring trusted communication between services.

Learning path: SPIFFE/Spire on Red Hat OpenShift

Red Hat solutions are built with comprehensive security in mind. They can help you build a zero trust foundation that allows data sovereignty while supporting the deployment and management of cloud-native and AI-driven workloads. Red Hat experts can help you get started with zero trust adoption in multicloud environments. 

Red Hat’s zero trust workload identity manager is a Red Hat OpenShift operator that simplifies the installation and lifecycle management of SPIFFE and SPIRE. You can install it on existing clusters, and it’s validated to work on Red Hat OpenShift and supported by comprehensive documentation for installation and troubleshooting.