SPIFFE and SPIRE for Secure Microservices Authentication

Enterprises these days have microservices distributed across a variety of environments — on-prem, cloud, containers, VMs, and more. Applications/services in such a heterogeneous system typically communicate with each other for various purposes, like data sharing.

This setup poses multiple security concerns for DevOps folks and architects, the primary one being ensuring proper authentication and establishing trust between service-to-service communication. And that is the tricky part.

Verifying the identity of services for secure authentication is challenging in a heterogeneous system for the following reasons:

• Communication happens across different environments/trust domains (think of communication between a database in AWS and a web application in GCP, or an on-prem data center and a cloud application, or an on-prem server and a VM located in a remote data center).
• Each trust domain has its own identity management mechanism, which makes interoperability challenging.
• Dynamic scaling of service endpoints adds additional complexity to identity management.
• Using long-lived passwords or API keys is not a viable solution, as they are not scalable and are more prone to be compromised.

These problems call for a universal identity solution that can not only span across different trust domains but can also provide consistent, short-lived, and provable identity to workloads. And that is where SPIFFE and SPIRE come in.

What Is SPIFFE?

Secure Production Identity Framework For Everyone (SPIFFE) is a set of open-source, platform-agnostic standards for securing the identity of workloads in a distributed system.

SPIFFE standard representation

Here, a workload can be any service/application that is isolated and spread across multiple nodes. The nodes can be hosted on any platform, such as cloud data centers, VMs, on-prem, or wherever the workload is running.

Implementing SPIFFE standards helps workloads communicating within and across trust domains to mutually authenticate and establish trust easily and reliably.

SPIFFE Components

Below are some components of SPIFFE:

• SPIFFE ID: It is a unique string/URI that identifies a workload. The string follows the format, spiffe://trust domain/workload identifier.
  
  For example, spiffe://imesh.ai/ns/abc/soc/xyz is a valid SPIFFE ID where imesh.ai is the trust domain, /ns/abc is the namespace name, and /soc/xyz is the service account name.

• SVID: SPIFFE Verifiable Identity Document (SVID) can be a JWT token or an X.509 certificate that encodes the SPIFFE ID. The issuing authority in the trust domain signs SVIDs, and workloads use them to prove their identity and authenticate with other workloads.
• Trust bundle: It is a collection of public keys that a destination workload will use to verify the SVID of the source workload. Trust bundles help to establish secure connections between services from different trust domains, often referred to as SPIFFE federations.
• SPIFFE workload API: The API distributes SVIDs and trust bundles to services in a trust domain. It handles the automatic rotation of these documents to enhance security.

As mentioned in the beginning, SPIFFE is a set of standards for securely identifying workloads, much like 0Auth is a set of specifications for authentication and authorization. For implementing SPIFFE standards, DevOps and architects can use SPIRE. 

What Is SPIRE?

SPIRE (SPIFFE Runtime Environment) is a production-ready implementation of SPIFFE standards. SPIRE leverages SPIFFE workload API to distribute and rotate SVIDs to workloads automatically so they can securely authenticate each other and implement mutual TLS in a dynamic environment.

SPIRE significantly eliminates the complexity and overhead associated with identity and secret management in heterogeneous systems, as it can provide a central platform for securely authenticating workloads across trust domains.

SPIRE Components

SPIRE has two major components: SPIRE server and SPIRE agent.

1. SPIRE server: It is the central certificate authority (CA) and identity (SVID) provider for the nodes and workloads in the entire system. SPIRE server keeps a registration entry of all workloads for which identity can be issued. The server issues and verifies the SVIDs of only registered nodes and workloads.
2. SPIRE agent: It runs on each node and exposes SPIFFE workload API locally for workloads in that specific node to get SVIDs. Note that the workloads only talk to the SPIRE agent. It is the agent that talks to the SPIRE server for identity distribution and verification (refer to the image below).

How Does SPIRE Work?

The SPIRE workflow starts with SPIRE server startup. The server generates a self-signed certificate (in the absence of a root CA), trust bundles, and exposes registration API for agents and workloads to register with the server. Finally, the SPIRE agent comes online.

There are two major steps in the SPIRE workflow after the agent starts up: node attestation and workload attestation.

Node Attestation

Node attestation is the process where the SPIRE agent in the node receives its SVID from the SPIRE server. It follows certain steps:

1. The SPIRE agent gets some verifiable platform details, such as platform ID, node name, node configs, etc., from the node.
2. The SPIRE agent communicates with the SPIRE server and shares platform details.
3. The SPIRE server independently queries the platform to verify platform details shared by the SPIRE agent.
4. The SPIRE server returns an SVID to the SPIRE agent once the identity verification is successfully completed.
   
   SPIRE node attestation

Once the agent is verified, the communication between the SPIRE server and the agent is secured with mTLS. The agent uses the trust bundle for mTLS, and the server authenticates the connection using SVID.

Workload Attestation

After the SPIRE server and the agent establish a secure connection (i.e., after the node attestation is completed), the agent queries the SPIRE server for the list of registration entries that pertain to the node. These registration entries define the list of services/workloads running on the node that can be attested and issued SVIDs from the server.

Once the SPIRE server gives the registration entries to the agent, the agent will return CSRs (Certificate Signing Requests) for each entry. Once the server signs the CSRs, the agent will receive workload SVIDs, which are distributed to the workloads through the workload API.

Just like the SPIRE server uniquely verifies the agent in the node attestation stage, the agent uniquely identifies a workload by comparing workload information provided by the workload attestor to the one in the registration entries. SPIRE agent provides SVID to the workload upon successful verification.

Benefits of Implementing SPIFFE and SPIRE

One of the primary benefits of implementing SPIFFE standards using SPIRE is the seamless interoperability between workloads, regardless of the infrastructure they are deployed in. This is crucial for DevOps and architects to build and run modern, complex application environments.

100% Zero Trust Security Across Trust Domains

Zero trust security architecture is the way forward for microservices in the current dynamic threat landscape. No entities in the entire system are taken for granted. They are continuously authenticated and have to prove their identity, no matter their trust domain.

SPIRE makes it easier for DevOps and architects to ensure zero trust networks within and across trust domains. SPIRE server acts as the central CA and provides short-lived, unique, and provable identity (SVID) to workloads in the whole system. The server frequently and automatically rotates the attested service identities for secure connection across organizational and cloud boundaries.

90% Reduction in Identity Management Challenges

It is tedious for DevOps engineers and administrators to manage identity and credentials across multiple platforms. Manually provisioning, maintaining, and rotating API keys, passwords, and certificates is a time-consuming and error-prone process. Besides, some engineers make the mistake of hard-coding secrets directly into the application code or expose them in git repos, leading to secret leakages.

SPIFFE and SPIRE reduce credentials and identity management complexities by automating them. SPIRE provides a centralized platform for issuing, maintaining, and rotating attested identities automatically. And there are no secrets shared between deployments during node and workload attestation stages. The nodes and workloads can securely register themselves to the SPIRE server in the runtime through registration API, which works well with microservices that scale dynamically.

99.99% Secure Containers and CI/CD Pipelines

Enterprises are adopting DevOps practices and have reduced time to market for applications with effective CI/CD pipelines. Attackers are aware of these changes in software delivery, and they carry out attacks to compromise the pipelines. A less secured CI/CD pipeline would let attackers push malicious containers/workloads into the platform, which would put the infrastructure at severe risk.

SPIRE helps DevOps folks prevent any malicious workloads from entering the system through CI/CD pipelines. It performs binary attestation, which means whenever the pipeline creates a new container image, the container hash is sent to SPIRE. SPIRE verifies the container hash before attesting the container with an identity document. This prevents attackers from pushing malicious containers or modifying containers in the container registry.

Integrating SPIFFE and SPIRE With Istio Service Mesh

Istio service mesh provides a dedicated infrastructure for networking, security, and observability of microservices in the cloud. It helps DevOps and architects simplify and secure traffic between services.

Integrating SPIFFE and SPIRE with Istio provides in-depth security by securely authenticating Istio workloads. The integration gives more flexibility for DevSecOps folks, as they can set and authenticate identities based on granular attributes and enable federation between trust domains.