
## TL;DR

We’ll deploy SPIRE on a local kind cluster, generate SPIFFE IDs for workloads, and use mutual TLS between two pods. This is how to go from zero to zero trust in Kubernetes.

What is SPIFFE/SPIRE?

- SPIFFE (Secure Production Identity Framework For Everyone): defines a framework for workload identity.
- SPIRE (SPIFFE Runtime Environment): the production-ready implementation of SPIFFE.

## Why You Should Care (Real World)

- Legacy apps don’t rotate secrets.
- TLS certs are static or manually managed.
- You can’t verify “who” a service is at runtime.
- SPIFFE solves this by issuing short-lived X.509 certificates tied to workload identity.

```mermaid
+---------------------+
|  SPIRE Server (K8s) |
+---------------------+
         |
         | gRPC (registration, trust bundles)
         v
+---------------------+         +----------------------+
| SPIRE Agent (DaemonSet) |<----->| Workload A (sidecarless) |
+---------------------+         +----------------------+
         |                                 |
         |                                 |
         v                                 v
  /spire-agent.sock                /spire-agent.sock
    (Unix socket)                    (shared via volumeMount)
```

- SPIRE Server runs as a StatefulSet
- SPIRE Agents run as DaemonSet, connect securely to server
- Workloads use a Unix socket to get certs

## What We’ll Build

- Setup kind cluster
- Install SPIRE Server and Agent
- Deploy two workloads: app-a and app-b
- Secure their communication using mTLS via SPIFFE

Pre-reqs:

```bash
brew install kind kubectl helm
```

Setup Kind:

```bash
cat <<EOF | kind create cluster --name spire --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: spire
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30443
        hostPort: 443
EOF
```

Get the Spire repo

```bash
git clone https://github.com/spiffe/spire-examples.git
cd spire-examples/k8s/simple_psat
```

Deploy SPIRE Server and Agent

```bash
kubectl apply -k .
```

This applies:

- spire-server.yaml
- spire-agent.yaml
- RBAC and namespace (via kustomize)

Register workloads 


Use spire-server running inside the cluster:

```bash
kubectl exec -n spire deploy/spire-server -- \
/opt/spire/bin/spire-server entry create \
  -spiffeID spiffe://example.org/ns/default/sa/default \
  -parentID spiffe://example.org/spire/agent/k8s_psat/my-cluster/node \
  -selector k8s:ns:default \
  -selector k8s:sa:default \
  -selector k8s:pod-label:app:app-a \
  -ttl 60
```

Repeat for app-b.

You’ll find more registration examples in:

```bash
examples/k8s/advanced/register-example.sh
```

## Verify Secure Communication

You’ll see app-a sending requests with a SPIFFE cert, app-b validating it.

```bash
kubectl logs -l app=app-b
```

Output should show:

```bash
Verified SPIFFE ID: spiffe://example.org/ns/default/sa/default
```

Diagram – Simplified

```mermaid
+---------+       mTLS       +---------+
| app-a   |----------------->| app-b   |
|         |    SPIFFE ID     |         |
| spiffe://.../app-a         | spiffe://.../app-b
+---------+                  +---------+
```

## Real-World Use Cases

- Zero-trust networking with Linkerd/Istio (replace cert-manager)
- Secretless app deployments (SPIFFE cert as identity token)
- Automatic rotation of certs every few minutes

## Bonus: Integrate with Istio or Linkerd

You can configure your mesh to trust SPIFFE identities instead of using static certs. Example (Istio):

```yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
```

Then use the SPIFFE trust domain in your AuthorizationPolicies.

## Conclusion

- SPIRE gives you automated workload identity via X.509 or JWT-SVID
- SPIFFE ID is portable across clusters, clouds, workloads
- You no longer rely on long-lived secrets or static TLS certs


Secure Your Kubernetes with SPIFFE + SPIRE: Zero-Trust Identity for Workloads

Posts tagged with: spire