Source linked

Vault and SPIFFE Close the Gap Between Identity and Authorization

hashicorp.com@systems_wire4 hours ago·Systems Engineering·2 comments

Workload identity alone proves who a service is but not what it can do. HashiCorp Vault bridges that gap with four SPIFFE-aligned patterns that turn trusted identities into short-lived credentials.

hashicorp vaultspiffespireworkload identityzero trustkubernetes

Most teams I talk to think workload identity is solved the moment their service gets an SVID. It's not. That cryptographic proof tells you the workload claims to be payments-api, but it says nothing about whether that API should modify a database schema, write to a specific table, or touch a production secret path.

Identity is not authorization. The hardest operational problem is translating a trusted identity into a consistent, secure access outcome across databases, cloud APIs, and internal services without scattering custom RBAC rules everywhere. HashiCorp's latest blog on Vault and SPIFFE lays out exactly how to solve that - and it doesn't require deploying SPIRE everywhere.

Why Identity Alone Isn't Enough

SPIFFE gives you a portable, platform-agnostic identity format: spiffe://trust-domain/workload-path. That's great for naming workloads uniformly across Kubernetes, VMs, and bare metal. But SPIFFE purposefully stops at execution. It doesn't define how to dynamically issue identities at runtime or how to translate them into access policies.

SPIRE is the runtime that operationalizes SPIFFE, with deep node and workload attestation. That's valuable when your threat model demands process-level verification. But SPIRE comes with real infrastructure commitments: agents, servers, trust configurations, plugins, and lifecycle overhead. Many organizations find their immediate bottleneck isn't attestation - it's the authorization step that follows.

This distinction keeps the architecture conversation honest. Vault acts as the control plane that ingests trusted identities and maps them to dynamic secrets, short-lived certificates, and credentials. Vault doesn't replace SPIRE-style attestation. But when you already trust platform-native identity sources (Kubernetes service accounts, AWS IAM, GCP, Azure, AppRole), Vault lets you adopt SPIFFE-aligned patterns immediately.

Four Patterns That Show the Architecture

The blog walks through four concrete scenarios in a HashiBank demo repository. Each one shows a different way to bridge identity and authorization.

1. Zero-trust mTLS between Kubernetes microservices. Vault authenticates payments-api and mtls-backend via Kubernetes service account tokens, then issues short-lived X.509 certificates with SPIFFE URI SANs. Vault steps out of the communication path entirely. The microservices execute a peer-to-peer mTLS handshake, verifying each other's SPIFFE IDs cryptographically at the application layer. Vault is the high-velocity identity issuer; the data plane consumes those identities independently.

2. Cross-network API authentication using JWT-SVID. The relationship-assistant workload authenticates to Vault, which mints a JWT-SVID from its SPIFFE secrets engine. The token's sub claim is dynamically templated from the Kubernetes identity, with custom metadata (business line, environment, customer data domain). Downstream APIs validate the token locally against Vault's public OIDC endpoint. This pattern extends to workload identity federation: the same JWT-SVID can be exchanged for cloud credentials in AWS STS, Azure Entra ID, or GCP IAM Pools, eliminating static multi-cloud keys.

3. SPIRE JWT-SVID authenticated into Vault. For organizations already running SPIRE, Vault ingests SPIRE-issued JWT-SVIDs via its SPIFFE auth method, validates them using the SPIRE federation bundle, and maps the identity to short-lived PostgreSQL credentials. No duplicated identity integrations required.

4. Vault as an upstream authority for SPIRE. SPIRE's server uses Vault's PKI engine as its upstream X.509 CA. Workload certificates chain back to Vault's root CA. This pattern gives organizations deep runtime attestation from SPIRE while using Vault as the hardened enterprise trust anchor.

What This Means for Your Workload Identity Strategy

Modern infrastructure demands two core capabilities: a portable workload identity format (SPIFFE) and a consistent way to authorize that identity (Vault). SPIRE remains essential when strict attestation is non-negotiable, but the clean separation of duties is the real insight.

Start with Vault as your workload identity control plane. It gives you the most direct path to map trusted identities to dynamic policies, secrets, and credentials across hybrid environments. The demo repository is runnable locally and tests all four scenarios. Clone it, break it, and see these zero-trust handshakes in action.


Source: Implementing workload identity with HashiCorp Vault and SPIFFE
Domain: hashicorp.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.