The Secret Problem Isn’t Secrets – It's Identity

Preamble

I recently stumbled across SPIRE/SPIFFE, and the more I read about it, the more its core idea resonated with me. Most organizations suffer from secret sprawl: IAM credentials for cloud workloads, SSH keys for devs, .env files passed around Slack, or API keys hardcoded into CI jobs. Revocation is a nightmare, auditing is incomplete, and breaches become treasure hunts for whatever got copied where.

A unified identity system spanning all my workloads, from developer machines to production services, would simplify my life as a security engineer.

How SPIFFE/SPIRE Solves Secret Sprawl

SPIFFE gives every workload its own digital passport: a short-lived X.509 certificate called an SVID, automatically issued by SPIRE or another compatible system. This certificate identifies the workload with a SPIFFE ID (e.g. spiffe://example.org/web/frontend). The certificate, which lets the service prove who it is without dragging around long-lived secrets, expires quickly and is rotated frequently so it's hard to steal or misuse.

But why do I need this if I already have a secrets manager? Because most secrets managers assume you’ve already solved identity. Vault wants a token. AWS Secrets Manager needs IAM credentials. But where do those come from in the first place? That’s the secret zero problem, securely bootstrapping trust without first handing out a secret, and SPIFFE solves it elegantly.

With the certificate, identity becomes the key to everything else. Inside your infra, you can often drop secrets entirely. Services use mutual TLS to prove who they are, and authorization logic decides what they can do. When secrets are still needed, like for third-party APIs, the SVID gates access. Workloads authenticate to your secrets manager using their identity and only get the secret they’re authorized for.

How It Works

A SPIFFE-enabled system fetches secrets securely on demand. The flow looks something like this:

Image showing how SPIFFE/SPIRE works - Different workload types obtain a certificate from the Spire Server via the Spire Agent which performs attestation

  1. Attestation: The SPIRE Agent first attests to the SPIRE Server through Node Attestation, proving the machine it's running on is trusted using cloud identity documents such as AWS instance identity. After the Server attests the node with out-of-band checks, the SPIRE Agent performs Workload Attestation, verifying the identity of workloads using markers like Kubernetes metadata or process runtime attributes.

  2. SVID Issuance: If the attestation checks out, the SPIRE Server issues a short-lived X.509-SVID, bound to a SPIFFE ID, which the SPIRE Agent then delivers to the workload.

  3. Secret Fetching: The workload uses its SVID to authenticate to a secrets manager, fetching the secrets it needs without ever storing credentials locally.

The Key Takeaway: Identity Comes First. Secrets Come Second.

SPIFFE/SPIRE doesn’t magically eliminate secrets. It changes how we think about access.

Instead of relying on possession of a token or API key, workloads prove their identity. That verified identity becomes the basis for gated, auditable access. You stop distributing secrets and start issuing trust. SPIFFE handles the identity while your app logic or policy engine decides what that identity is authorized to do.

Does this fix everything? Of course not. You'll likely need to use a sidecar for your legacy apps, or build an auth library that abstracts the complexity of SVID retrieval and usage so your devs can focus on business logic. And if your team is still uploading .env files to Slack, you’ve got other problems.

And yeah, it’s another piece of infra to manage. You’ll have to think about SPIRE agent health, the SPIRE server DB/read replica health, and all the usual operational stuff. In return, you gain observability, revocation, and a verifiable audit trail.

What this series covers

I’ll walk through setting up SPIRE on AWS and using it as the single source of identity for everything from dev machines to EKS workloads.

This won’t cover HA deployments, multi-region SPIRE, or plugging into enterprise PKI. But it’ll go over the basics and you can swap out the toy pieces for enterprise-grade alternatives that meet your security posture.

If you’ve ever wished for one source of truth for identity across your cloud, clusters, laptops, and runtime services — keep reading.

Part 1: Local Dev Authentication with SPIRE + IAM Roles Anywhere
Part 2: SPIRE-Powered Access to AWS VPN from Dev Machines