SPIRE is typically is the default answer for SPIFFE workload identity, but it's not the only one. If you're already running HashiCorp Vault in your environment, you've got everything you need to issue SPIFFE-compliant SVIDs without adding yet another control plane.

Vault's PKI secrets engine can mint X.509 SVIDs directly, with the SPIFFE ID embedded as a URI SAN. The Vault Agent handles authentication, retrieval, and rotation. And once a workload has an SVID, the SPIFFE auth method lets it authenticate back to Vault for any other secrets it needs.

This post walks through the architecture, the workflow, and the gotchas worth knowing about before going down this path.

---

Why Skip SPIRE?

SPIRE works. That's not the issue. The issue is that SPIRE is a separate platform with its own server, agents, datastore, upgrade cycle, and operational model. If you're already running Vault for secrets and PKI, adding SPIRE means standing up a second trust system that solves problems Vault can already solve.

A few specific reasons teams look at consolidating:

• Standardize on one authentication surface. Workloads authenticate to Vault using methods that already exist (Kubernetes, AWS, GCP, AppRole). One auth model, one policy language, one audit log.
• Centralize cert and token issuance. Vault becomes the single issuer for both workload identities and secrets. No splitting cert authority across platforms.
• Eliminate static tokens. A workload that gets its SVID from Vault can use the SPIFFE auth method to authenticate back to Vault for any additional secrets - no static tokens, no app-rolled credentials sitting in config.
• Reduce operational surface area. One platform to operate, patch, upgrade, back up, and monitor instead of two.

If you've already invested in Vault, this is leveraging what you have instead of investing your time, knowledge, and operational burdens on something new.

---

The Architecture

Specifically for a Kubernetes workload, here's the flow once you see it laid out:

1. Vault Agent authenticates to the Vault cluster using the Kubernetes auth method (or AWS, GCP, etc., depending on where the workload runs).
2. Vault Agent requests an X.509 SVID from the PKI secrets engine. The certificate includes the SPIFFE ID as a URI SAN, for example spiffe://example.com/payments/api.
3. Vault Agent writes the cert to a shared volume that the workload container can read.
4. The workload reads the cert from the shared volume and uses it for mTLS or any identity-based auth.
5. Optional: The workload uses its SVID to authenticate back to Vault via the SPIFFE auth method and pulls any additional secrets it needs (static, dynamic, or otherwise). You could, of course, grab additional secrets using the Vault Agent, but, in general, the workload isn't aware of the Vault Agent, so this optional configuration gives the workload the ability to authenticate directly, if it makes sense.

The Vault Agent also handles renewal in the background. As the cert nears expiration, Vault Agent requests a new one and writes it to disk.

---

Why Vault Handles This Well

Three things make this work.

1. PKI with SPIFFE-aware certificate roles. Vault's PKI engine issues certificates with arbitrary URI SANs. Configure a role that allows spiffe:// URIs and you've got a SPIFFE-compliant issuer:

vault write pki/roles/spiffe \
  allowed_uri_sans="spiffe://example.com/*" \
  ttl="60m" \
  max_ttl="60m" \
  key_type="ec" \
  key_bits=256

The 60-minute TTL matches SPIRE's default, but you can tune it.

2. Vault Agent as the workload identity helper. Vault Agent runs as a sidecar, authenticates on behalf of the workload, retrieves the cert, writes it to disk, and handles renewal. The workload never needs to know how to talk to Vault directly.

3. SPIFFE auth method. Once the workload has an SVID, it can authenticate to Vault using the SPIFFE auth method. Point the auth method at the PKI engine's trust bundle and Vault validates incoming SVIDs against it. The workload gets a path to retrieve any other secrets it needs without ever holding or managing the lifecycle a static Vault token.

---

Putting It Together

A minimal deployment looks like this.

Vault PKI configuration:

# Enable PKI
vault secrets enable -path=pki pki
vault secrets tune -max-lease-ttl=8760h pki

# Generate or import a root/intermediate CA
# (omitted for brevity)

# Create a SPIFFE-aware role
vault write pki/roles/spiffe \
  allowed_uri_sans="spiffe://example.com/*" \
  ttl="60m" \
  max_ttl="60m" \
  key_type="ec" \
  key_bits=256

Vault Agent sidecar config:

auto_auth {
  method "kubernetes" {
    config = {
      role = "payments-api"
    }
  }

  sink "file" {
    config = {
      path = "/vault/secrets/token"
    }
  }
}

template {
  source      = "/vault/templates/svid.tpl"
  destination = "/vault/secrets/svid.pem"
}

Template (svid.tpl):

{{ with secret "pki/issue/spiffe" "common_name=payments-api" "uri_sans=spiffe://example.com/payments/api" "ttl=60m" }}
{{ .Data.certificate }}
{{ .Data.private_key }}
{{ end }}

The workload container mounts the same volume and reads /vault/secrets/svid.pem. That's the entire integration.

---

A Few Nuances Worth Knowing

Vault doesn't behave exactly like SPIRE, and a few differences are worth planning for upfront.

Certificate format

Vault currently exports X.509 certificates in PEM format. If your workload expects PKCS12 (common for Java and Kafka clients), you'll need a post-render hook or a small sidecar step to convert.

The good news: Vault 2.1 should add native PKCS12 support for certificates. If your timeline allows, plan around the conversion today and rip it out once 2.1 ships.

Authentication model

SPIRE uses workload attestation. It inspects the running workload (process attributes, Kubernetes labels, namespaces, service accounts) and decides what identity to issue. Vault doesn't do this. Instead, the Vault Agent authenticates to Vault using one of Vault's existing auth methods before it can request a cert.

In practice:

• On Kubernetes, each Vault Agent sidecar uses the Kubernetes auth method tied to a specific service account. The agent requests the single SVID assigned to that workload.
• On traditional machines, a single Vault Agent can authenticate once and retrieve multiple certificates, writing each to its respective file location.

You're trading workload attestation for whatever Vault auth method fits your platform. For most teams, that's an acceptable trade. For teams that rely heavily on SPIRE's selectors, look at this one carefully.

Rotation behavior

SPIRE rotates SVIDs transparently and exposes them through the Workload API. Workloads pick up the new cert through that API.

With Vault, rotation happens on disk. Vault Agent writes the new cert to the shared volume and the workload has to reload it. For Java and Kafka clients, that means implementing dynamic SSL reload. Some libraries handle this cleanly; others don't.

Keep the TTL short enough that compromise windows stay small, but long enough that you're not thrashing on reloads. 60 minutes is a reasonable starting point.

---

What I'm Still Watching

A few things are worth tracking before betting your platform on this approach:

• PKCS12 support in Vault 2.1. Removes the conversion step and makes Java/Kafka integration cleaner.
• First-class SPIFFE support on the Vault roadmap. Vault's PKI engine can issue SPIFFE-compatible certs today, but a dedicated SPIFFE workflow would tighten this further.
• Workload attestation gaps. If you depend on SPIRE's selector-based attestation, you'll need to map those concepts onto Vault auth method roles, and it isn't always one-to-one.

---

Final Thoughts

If Vault is already in your environment, you don't need a separate platform to handle SPIFFE workload identity. You can consolidate cert issuance, authentication, and secret retrieval onto one platform. One audit log, one policy surface, one set of operational runbooks.

The trade-offs are real: PEM-to-PKCS12 conversion, dynamic SSL reload, and the loss of workload attestation. Whether those trade-offs make sense depends on your environment and what you'd need SPIFFE for.

For most teams I've worked with, leveraging an existing Vault footprint beats standing up a second platform. The team already knows how to operate Vault. The infrastructure is already there. Issuing SVIDs becomes one more thing Vault does.

If you're going down this path, start in a non-production environment. Get a single workload running with Vault-issued SVIDs end-to-end before you build anything bigger. The architecture is straightforward, but the operational details (rotation, reload, format conversion) are where the real work lives.

---

Want to go deeper on Vault? Check out my HashiCorp Certified: Vault Associate (w/ Hands-On Labs) course for hands-on coverage of PKI, auth methods, and Vault Agent in production scenarios.