Manage Machine Identities with SPIFFE and SPIRE

By Kokil Thapa | Last reviewed: September 2026

Every production system eventually outgrows static API keys baked into config files. Services talk to other services across VMs, containers, and cloud regions. When one key leaks, you rotate dozens of credentials by hand and hope nothing breaks. To manage machine identities with SPIFFE and SPIRE, you issue short-lived cryptographic identities to workloads instead of shared secrets. SPIFFE defines the standard; SPIRE is the reference runtime that mints and rotates those identities at scale. If you already run REST APIs with service-to-service auth, this model fits cleanly between your app layer and your infrastructure.

What Does It Mean to Manage Machine Identities with SPIFFE and SPIRE?

SPIFFE (Secure Production Identity Framework For Everyone) is a CNCF standard for workload identity. SPIRE is its production-grade implementation. Together they answer one question: how does this process prove who it is?

A machine identity here is not a human login. It is a verifiable ID bound to a running workload—a pod, a systemd service, a batch job. Each identity gets a SPIFFE ID like spiffe://prod.example.com/ns/payments/sa/billing and a corresponding SVID (SPIFFE Verifiable Identity Document).

Human auth tools such as Keycloak for user sessions solve a different problem. SPIFFE targets east-west traffic: service A calling service B inside your perimeter. That overlap matters on platforms like client portals with document APIs, where a web tier, queue worker, and storage service all need distinct credentials.

Core vocabulary

• Trust domain — the SPIFFE namespace root (e.g. prod.example.com).
• SVID — the credential SPIRE issues; usually an X.509 cert or JWT.
• Attestation — proof that a workload matches a registration entry.
• Workload API — local socket where processes fetch current SVIDs.

The official overview lives at spiffe.io. Read that once, then focus on SPIRE deployment mechanics.

How Do You Install and Configure SPIRE for Production Workloads?

SPIRE has two main components. The Server holds the trust anchor and signing keys. Agents run on every node and attest local processes. Start small: one Server, two Agents, two test services.

Step 1: Deploy the SPIRE Server

Use the upstream Helm chart or raw manifests. On a single-node lab, SQLite backing store is fine. Production clusters should use MySQL 9.7 or PostgreSQL 18—databases you likely already run for enterprise applications.

# server.conf (minimal excerpt)
server {
  bind_address = "0.0.0.0"
  bind_port = "8081"
  trust_domain = "prod.example.com"
  data_dir = "/run/spire/data"
  log_level = "INFO"

  ca_key_type = "rsa-2048"

  ca_subject {
    country = ["US"]
    organization = ["Example Corp"]
    common_name = "prod.example.com"
  }
}

plugins {
  DataStore "sql" {
    plugin_data {
      database_type = "mysql"
      connection_string = "root:@tcp(localhost)/spire"
    }
  }
  NodeAttestor "k8s_psat" {
    plugin_data {
      clusters = {
        "prod-cluster" = {
          service_account_allow_list = ["spire:spire-agent"]
        }
      }
    }
  }
}

Step 2: Run SPIRE Agents on each node

Agents connect to the Server, perform node attestation, and expose the Workload API on a Unix socket. On Linux hosts you maintain via system administration practices, treat the Agent like any critical daemon—monitor restarts and disk use under /run/spire.

# agent.conf (minimal excerpt)
agent {
  data_dir = "/run/spire/agent"
  log_level = "INFO"
  server_address = "spire-server"
  server_port = "8081"
  socket_path = "/run/spire/sockets/agent.sock"
  trust_domain = "prod.example.com"
}

plugins {
  NodeAttestor "k8s_psat" {
    plugin_data {
      cluster = "prod-cluster"
    }
  }
  WorkloadAttestor "k8s" {
    plugin_data {
      skip_kubelet_verification = false
    }
  }
  KeyManager "memory" {
    plugin_data {}
  }
}

Step 3: Register workloads

Each workload needs a registration entry mapping attestation selectors to a SPIFFE ID path.

spire-server entry create \
  -spiffeID spiffe://prod.example.com/ns/payments/sa/billing \
  -parentID spiffe://prod.example.com/spire/agent/k8s_psat/prod-cluster/node-name \
  -selector k8s:ns:payments \
  -selector k8s:sa:billing

In Kubernetes, the admission controller pattern can automate these entries when pods start. Many teams use the SPIFFE CSI driver or init containers to mount SVIDs into the pod filesystem.

How Does SPIRE Attestation Replace Long-Lived API Keys?

Static keys in environment variables are the default on many Laravel and PHP deployments I've maintained. They work until someone commits .env to git or a backup leaks. SPIRE removes the long-lived secret entirely.

Attestation is a chain of checks. First the Agent proves the node is legitimate (node attestation). Then it proves the process requesting an SVID matches registered selectors (workload attestation). Only then does the Server sign an SVID.

This model parallels workload identity federation in cloud IAM, but it runs on your infrastructure. AWS IRSA, GCP Workload Identity, and Azure federated credentials solve the same problem inside one cloud. SPIFFE works across clouds, bare metal, and hybrid clusters managed with tools like Rancher.

Attestation selectors you will use daily

1. Kubernetes: k8s:ns:payments, k8s:sa:billing, k8s:pod-label:app:api
2. Unix: unix:uid:1000, unix:gid:1000, unix:path:/opt/api/bin
3. Docker: docker:label:role:worker, docker:image_id:sha256:…

Combine selectors narrowly. A registration that only checks namespace without service account is too broad. An attacker who escapes to that namespace could impersonate your service.

Pair SPIRE with pipeline hygiene from managing secrets safely in CI/CD. SPIRE handles runtime identity; your pipeline still must not embed production keys in build artefacts.

Which SVID Format Should You Choose: X.509 or JWT?

SPIRE can issue both X.509-SVIDs and JWT-SVIDs. Pick based on how your services terminate TLS and validate callers.

For greenfield microservices behind a service mesh, X.509-SVID with automatic mTLS is the usual choice. For Laravel or PHP monoliths calling internal APIs over HTTPS, JWT-SVID in an Authorization: Bearer header is often simpler to adopt without rewriting your HTTP stack.

Fetch an X.509-SVID from the Workload API using the spire-agent api fetch x509 command or a client library. Validate the peer chain against the trust bundle SPIRE publishes. Never hard-code CA certificates in application code; subscribe to bundle updates.

How Do You Operate SPIRE Safely in Kubernetes and Multi-Cloud Setups?

Production SPIRE is as much operations as installation. I've seen clusters where SPIRE worked in staging but failed silently in prod because node labels changed after a config drift during a node pool upgrade.

High availability for the SPIRE Server

Run at least three Server replicas behind a load balancer. Use a shared SQL datastore with proper backups—the same discipline you apply to application databases. Store signing keys in a cloud KMS or HashiCorp Vault rather than plain disk when possible. If you already centralise secrets with AWS Secrets Manager, keep SPIRE's CA keys at that same trust tier.

Federation across trust domains

Large orgs split trust domains by environment or region: spiffe://prod.example.com and spiffe://staging.example.com. SPIFFE federation lets workloads in one domain validate SVIDs from another via bundle endpoints. This resembles identity federation across cloud providers, but under your own SPIFFE roots.

Integration with existing platforms

• Istio / Envoy — enable SPIFFE-compatible mTLS; Envoy fetches certs from the Workload API.
• Linkerd — uses its own identity by default; SPIRE integration is possible via custom trust anchors.
• systemd services — run Agents on bare metal; attest with unix: selectors tied to unit files from systemd service management.
• HashiCorp Vault — Vault can consume SPIFFE auth for secret access; SPIRE handles identity, Vault handles secret storage.

On hybrid setups—say a Kathmandu-hosted API talking to AWS workers—SPIFFE gives you one identity model instead of juggling cloud-specific IAM for each hop. That matters for custom software with multi-region backends.

Monitoring and failure modes

Watch these metrics and logs:

• Agent connection count to Server (drops mean node attestation failure).
• SVID issuance rate and error codes (permission denied = bad selectors).
• Time-to-rotate before cert expiry (should stay well under TTL).
• Registration entry count vs running pod count (gaps mean unregistered workloads).

Common failures: kubelet certificate rotation breaking PSAT attestation, overly broad selectors after a namespace restructure, and firewall rules blocking Agent-to-Server gRPC on port 8081. Document runbooks alongside your support and maintenance procedures.

The SPIRE project documentation at spiffe.io SPIRE docs covers plugin catalogues and federation setup in detail. Cross-check your Server and Agent versions against the compatibility matrix before upgrading.

When Should You Adopt SPIFFE Instead of Sticking with API Keys?

SPIRE adds moving parts. Skip it for a single-server WordPress site. Adopt it when east-west traffic volume, compliance pressure, or breach risk justify operational overhead.

Strong signals you are ready:

• Ten or more internal services exchanging credentials.
• Compliance asks for non-exportable, rotatable workload credentials.
• You run multiple Kubernetes clusters or hybrid cloud and IAM sprawl hurts.
• Micro-segmentation or zero-trust initiatives need cryptographic proof of caller identity.

Weak signals—stay with short-lived tokens from Vault or cloud IAM until team capacity grows:

• One monolith plus a database.
• No container orchestration and no plan to add it.
• Team lacks Linux service debugging skills for Agent troubleshooting.

Incremental adoption works. Start with one namespace and mTLS between two services. Expand registration entries as you prove stability. On payment-heavy systems—like eCommerce platforms handling order and fulfilment APIs—protect the payment callback service first. It is the highest-value east-west hop.

Key Takeaways

• SPIFFE defines workload identity; SPIRE mints short-lived SVIDs so you can manage machine identities without static API keys.
• Deploy HA SPIRE Servers, Agents on every node, and narrow workload registration selectors tied to namespace, service account, or process attributes.
• Choose X.509-SVID for mTLS at the proxy layer; choose JWT-SVID when apps already validate bearer tokens over HTTPS.
• Treat attestation misconfiguration as a security bug—broad selectors are equivalent to shared passwords.
• Use federation when you operate multiple trust domains across regions or clouds.
• Monitor SVID issuance errors and Agent connectivity before cert expiry incidents reach production traffic.

People Also Ask

What is the difference between SPIFFE and SPIRE?

SPIFFE is the open standard for workload identity format, APIs, and trust bundles. SPIRE is the CNCF reference implementation that runs Servers and Agents to issue and rotate SVIDs. You adopt SPIFFE concepts; you deploy SPIRE (or a compatible implementation) to make them work.

Does SPIRE replace Kubernetes service accounts?

No. Kubernetes service accounts still identify pods inside the cluster. SPIRE uses them as attestation inputs to issue portable cryptographic identities. Those SVIDs can authenticate calls outside the cluster and across trust domains where Kubernetes RBAC alone does not reach.

How often do SPIRE SVIDs rotate?

Default X.509-SVID TTL is often one hour, with automatic rotation before expiry. JWT-SVIDs typically live five to twenty minutes. You configure TTL per registration entry. Shorter TTL reduces blast radius but increases Workload API fetch frequency.

Can SPIRE work with Laravel or PHP applications?

Yes. Sidecar proxies handle mTLS for X.509-SVIDs without PHP changes. For direct integration, use JWT-SVIDs fetched from the Workload API socket and attach them as Bearer tokens on outbound Guzzle or HTTP client calls. Validate incoming JWTs against SPIRE's JWKS endpoint in middleware.

Build Workload Identity Into Your Architecture Early

Static secrets do not scale past a handful of services. To manage machine identities with SPIFFE and SPIRE, start with one trust domain, register your highest-risk workloads first, and expand as your team learns Agent operations. The payoff is automatic rotation, cryptographic caller proof, and one identity model across clouds and bare metal. If you want help designing service auth for a new platform—or hardening an existing API mesh—contact us to talk through trust domains, attestation rules, and a phased rollout plan. For background on the author’s infrastructure work, see about me and the project portfolio.