SPIFFE: a stable identity for constantly evolving applications

In our previous article, eBPF took the form of a turnstile placed as close as possible to the exchanges between applications. Such a control, however, only makes full sense if you know which badge to recognise — and can make sure it belongs to the one presenting it.

In Kubernetes, the components that run an application are ephemeral by nature. Pods disappear and are reborn, their addresses change, their number varies with load and deployments. In the midst of this constant motion, one thing must nevertheless remain stable: the identity of the service, its role and the rights associated with it.

This is precisely what SPIFFE proposes: giving applications and services a verifiable identity, as independent as possible from what never stops changing in their runtime environment — an IP address, a container or a machine.

The principle sounds simple. Its implementation is far less so. The right badge must be assigned to the right service, renewed without interrupting exchanges, and must stop opening doors as soon as the associated rights disappear.

What SPIFFE makes possible, concretely

SPIFFE is a set of specifications intended to give a verifiable identity to applications and services, which the standard refers to as workloads. This can be a service, a process or, more broadly, a component running in a distributed environment.

In our building metaphor, SPIFFE defines the badge. It makes it possible to recognise the service presenting itself, independently of its IP address, its container or the machine hosting it.

SPIFFE thus answers a first question: who is presenting itself? Authorisation rules then determine what it may do. An authentic badge therefore does not open every door.

The badge must survive the replacement of the instance

In Kubernetes, a Pod can disappear and be recreated a few seconds later. The new instance may receive another IP address, run on another node and, during a deployment, temporarily coexist with the one it replaces.

For the user, nothing has really changed: it is still the same application. For the infrastructure, on the other hand, almost everything has changed.

Identity therefore cannot remain attached to a particular instance. It must follow the role of the service and be recovered by the new instance, without being obtainable by another component that would come to take its place.

This stability does not mean the badge stays identical over time. The logical identity of the service can remain constant, while the cryptographic elements used to prove it are renewed regularly.

This is where a significant part of service continuity plays out. If a legitimate application can no longer obtain or renew its identity, it can lose access to its dependencies. Conversely, an identity assigned to the wrong component can allow it to present itself as a recognised service.

The challenge is therefore not only to keep a stable identity in a moving environment. It is above all to guarantee, over time, that this identity remains associated with the right service.

A badge only has value if it is handed to the right service

A badge only has value if the system issuing it knows precisely to whom it is handing it.

In a dynamic architecture, this step is decisive. Before assigning an identity, the system must make sure that the component requesting it truly corresponds to the service it claims to represent. This verification relies on several pieces of information from the orchestrator, the runtime environment and the system itself.

An error at this stage does not merely produce an incorrect badge. It can give an application an identity that the rest of the architecture will consider perfectly legitimate. The risk then changes in nature. It is no longer only about protecting a key, a secret or a certificate, but about guaranteeing the reliability of the whole chain linking an application to the identity assigned to it.

This chain must also remain legible. When an identity is used, it must be possible to find the service concerned, understand under which conditions it was issued and determine the perimeter in which it was meant to be recognised.

Because an identity that is technically reliable, but impossible to clearly link to an application or a business service, ultimately contributes little to incident analysis — and hardly more to auditing.

Transitions put trust to the test

The elements that allow an application to prove its identity have a limited lifetime. They must therefore be renewed regularly, without interrupting the operation of the service.

This rotation reduces the time during which an old or compromised identity can remain exploitable. It nevertheless introduces an additional constraint: making trust evolve without breaking the communications it protects.

A late renewal can be enough to interrupt the exchanges of a perfectly legitimate application. A poorly synchronised transition can, for its part, lead two components to temporarily no longer recognise the same authorities. Conversely, a still-valid identity can persist even though the rights associated with the service have just changed.

These gaps appear in particular when a service changes role, leaves an environment or loses access to a dependency. The badge can still be authentic while the door should no longer open. The opposite situation is just as problematic: the service keeps its rights, but can no longer present a recognised identity.

In one case, the risk concerns security; in the other, availability.

It is precisely in these moments of transition that our experimentation becomes most interesting. Nominal operation shows that two services know how to recognise each other. Renewals, restarts, role changes or authorisation withdrawals make it possible to observe what happens when trust must evolve without the system stopping.

A trust domain is not an access right

SPIFFE organises identities within trust domains. Each of them constitutes a perimeter in which identities are established and verified from the same root of trust.

This is where SPIRE comes in, one of the main implementations of SPIFFE. It provides the infrastructure responsible for establishing these identities, delivering them to workloads and administering the trust domain to which they belong.

In our building, the trust domain corresponds to the authority that issues the badges and makes it possible to verify their authenticity. Recognising this authority, however, does not mean that every badge it issues opens the same doors.

This distinction becomes essential when several clusters, environments or organisations must communicate. A production platform does not carry the same risks as a development environment; likewise, an identity coming from a partner or another cluster should not necessarily enjoy the same level of trust as an internal identity.

Making identity usable

A cryptographically verifiable identity is not enough to make an architecture intelligible. Its value also depends on how it is taken up by applications, security mechanisms and observation tools. The same service should not appear successively under addresses, technical names or certificates that are hard to reconcile.

This coherence takes on its full importance during an incident. An unknown identity, an expired document, a refused authorisation or an interrupted communication can produce similar symptoms, while pointing to very different causes.

Identity must then make it possible to reconstruct the exchanges: identifying the services involved, retrieving the identities used and understanding the rules that led to accepting or refusing a communication.

SPIFFE thus provides a common base for naming and authenticating applications. Its value fully appears when this identity can be linked to the rules applied and the events observed.

A second foundation for our projects

With eBPF, we explored the turnstile: the point where a communication can be observed or controlled as close as possible to the system.

With SPIFFE, we work on the badge presented to that turnstile: an identity that must remain coherent while the application changes instance, machine or environment.

These two experiments address different but complementary problems. Identity states which service is presenting itself. Rules define what it may reach. Controls enforce these decisions on a given perimeter. Observation must then make it possible to explain what actually happened.

The badge and the turnstile only make sense together. It is in the coherence between identity, authorisation, control of exchanges and operational constraints that the Zero Trust foundations of our applications are built.