SPIFFE / SPIRE

Definition of Spiffe and Spire

SPIFFE is a standard for authentication (‘who’, not authorization / ‘what’) in heterogeneous environments.

Conventional authentication works on platform (e.g., OS user) or host ( e.g. node’s IP address) level, which are both too ‘low’ for cloud native environments, as those are subject to constant change. SPIFFE authenticates any kind of workloads against each other. Workloads are instances of software like a microservice, a database, etc.- those that are more granular than a platform or a host.

SPIFFE is in essence a specification defining the SPIFFE ID, the SVID, and an API to obtain the SVID.

SPIFFE IDs are URIs uniquely identifying a workload, in the format spiffe://trust domain/workload identifier, e.g., spiffe://acme.com/billing/payments

A ‘SPIFFE Verifiable Identity Document’ (SVID) is a document that a workload proves its identity with, signed by an authority (called ‘trust domain’), in form of either a X.509 certificate or a JSON Web Token (as of now).

SPIRE is the reference implementation of SPIFFE. It consists of (a) a server that registers all workloads and acts as authentication authority, and (b) agents that are installed on each node, exposing the SPIFFE API to the workloads and interacting with the server.

SPIRE installs well in Kubernetes clusters, with the agents being deployed by a DaemonSet running a pod with an agent on each worker node.

SPIRE server and agents (source: https://spiffe.io/spire/concepts)

Technology Evaluation

SPIFFE / SPIRE has significant advantages, including:

• Workloads can be user-related or not. This ends the usage of problematic ‘system users’, as in: “We need to define a system user in the DB that systems A and B use when calling it. The system user’s password must never expire, otherwise our production system stands still!”
• Workloads can be Microservices, making SPIFFE a natural choice for Microservice architectures.
• SPIFFE can even be useful if systems only provide legacy authentication like user/ password. Those passwords can be stored in password vaults, but by itself this only moves authentication issues (from “who has access to the system?” to “who has access to the vault?"). However, if the vault containing the passwords supports authentication scope and authentication to the vault is done via SPIFFE, then benefits of token-based authentication can be realized.
• X.509 support implies that SPIFFE supports TLS, in particular also OAuth utilizing mutual TLS authentication with X.509 certificates.

The SPIRE server becomes the single source of authentication truth, which of course impacts the requirements for this server’s availability.

Market - Current Adoption

Currently, both SPIFFE and SPIRE are on CNCF ‘graduated’ level.

Current adoption of SPIFFE includes:

• On application level (ISO/OSI Layer 7): Istio Service Meshes (via Istio component Envoy)
• On network level (ISO/OSI Layers 2-3): the CNCF Network Service Mesh (NSM) project

Market - Outlook

SPIFFE allows token-based authentication at the right level of granularity, and in a cloud-native way.

We consider it a major step forward in the security area, which tends to be lagging behind the progress in the Cloud area, factually often making Cloud adoption a security risk. Thus, SPIFFE/SPIRE is highly welcome and adoption is recommended.

Earlier problems (e.g. vulnerability of the SPIRE server) have been solved and the product and standard is now at a sufficient level of maturity for enterprise usage.