Learn IAM
Learn IAM

Deploy SPIRE (SPIFFE) in Minikube with Helm and Issue SVIDs

Intermediate60–90 minLast reviewed: 2026-02-01

This tutorial sets up SPIRE (the reference implementation of SPIFFE) inside a local Kubernetes lab (minikube) using Helm.

You’ll deploy the SPIRE Server and Agent, register a workload, and retrieve an X.509 SVID to prove workload identity end-to-end.

What you’ll build

  • A minikube cluster running SPIRE Server + Agent
  • A registered workload with a SPIFFE ID like spiffe://example.org/ns/default/sa/demo
  • A verification flow where the workload retrieves (and rotates) an X.509 SVID

Prerequisites

  • minikube + kubectl
  • helm
  • Enough local resources (2 CPUs / 4GB RAM minimum)

Architecture overview

Diagram

Step 1 — Start minikube

bash
minikube start
kubectl get nodes

Step 2 — Install SPIRE with Helm

  1. Add the SPIRE Helm repo (or use upstream chart source you standardize on).

  2. Install into a dedicated namespace:

bash
kubectl create namespace spire
helm install spire \ 
  spiffe/spire \ 
  --namespace spire

(We’ll pin versions once we settle on a chart + SPIRE version policy.)

Step 3 — Confirm server/agent are running

bash
kubectl -n spire get pods

You should see:

  • SPIRE Server pod running
  • SPIRE Agent running on the node (DaemonSet)

Step 4 — Register a workload entry

There are multiple ways to register entries; for local labs, the simplest path is:

  • exec into the SPIRE Server pod
  • create an entry matching a Kubernetes selector (namespace + service account)

Example (conceptual):

  • SPIFFE ID: spiffe://example.org/ns/default/sa/demo
  • Selectors: k8s:ns:default, k8s:sa:demo

Step 5 — Deploy a demo workload that fetches an SVID

  1. Create a service account:
bash
kubectl -n default create sa demo

  1. Deploy a demo pod that can talk to the Workload API (often via a Unix socket mounted from the agent).

  2. From inside the pod, fetch an X.509 SVID and print the SPIFFE ID.

Step 6 — Verify rotation

Wait a few minutes and fetch again. You should observe:

  • certificates rotate on a schedule
  • SPIFFE ID remains stable

Troubleshooting

  • Selectors don’t match: most common issue; confirm namespace + service account
  • Agent can’t attest: check server logs and agent logs
  • Workload can’t reach Workload API: confirm socket mount / permissions

Hardening / production notes

  • Pick the right node attestation method for your environment
  • Treat SPIFFE IDs as identity contracts: stable naming matters
  • Plan operationally for CA rotation and failure modes

Cleanup

bash
helm uninstall spire -n spire
kubectl delete namespace spire

Where to go next