SPIFFE/SPIRE on Kubernetes: Complete Installation and Configuration Guide

Introduction: From VMs to Kubernetes-Native Zero Trust#

In my previous post on building a secure service mesh without Kubernetes, I demonstrated how to implement SPIFFE/SPIRE on traditional VMs. Today, we’re taking that knowledge to the cloud-native world with a comprehensive guide to deploying SPIFFE/SPIRE natively on Kubernetes.

While the core concepts remain the same—cryptographic workload identities, attestation, and zero-trust networking—the Kubernetes implementation brings unique advantages: dynamic workload management, native integration with Kubernetes primitives, and seamless scaling. This guide bridges the gap between traditional infrastructure and cloud-native security.

Why SPIFFE/SPIRE on Kubernetes?#

Before diving into implementation, let’s understand why SPIFFE/SPIRE has become the de facto standard for workload identity in Kubernetes:

The Identity Challenge in Kubernetes#

1
graph TD
2
    subgraph "Traditional Approach"
3
        A[Pod A] -->|IP-based trust| B[Pod B]
4
        B -->|Static credentials| C[Database]
5
        A -->|Hardcoded secrets| D[External API]
6
    end
7

8
    subgraph "SPIFFE/SPIRE Approach"
9
        E[Pod A<br/>SPIFFE ID: spiffe://domain/ns/prod/sa/frontend]
10
        F[Pod B<br/>SPIFFE ID: spiffe://domain/ns/prod/sa/backend]
11
        G[Database<br/>SPIFFE ID: spiffe://domain/ns/data/sa/postgres]
12
        H[External API]
13

14
        E -->|mTLS with SVID| F
15
        F -->|mTLS with SVID| G
16
        E -->|JWT SVID| H
17
    end
18

19
    style A fill:#ff9999
20
    style B fill:#ff9999
21
    style E fill:#99ff99
22
    style F fill:#99ff99

Key Benefits#

Dynamic Identity Management: Automatic identity issuance and rotation
Platform Agnostic: Works across clouds, on-premises, and hybrid environments
Kubernetes Native: Leverages Service Accounts, Namespaces, and other K8s primitives
Zero Trust by Default: No implicit trust based on network location
Attestation Flexibility: Multiple methods from K8s tokens to hardware TPMs

Architecture Overview#

Let’s understand the SPIFFE/SPIRE architecture in a Kubernetes context:

1
graph TB
2
    subgraph "Control Plane Node"
3
        SS[SPIRE Server]
4
        ETCD[etcd/PostgreSQL]
5
        REG[Registration API]
6
        SS --> ETCD
7
        SS --> REG
8
    end
9

10
    subgraph "Worker Node 1"
11
        SA1[SPIRE Agent]
12
        CSI1[SPIFFE CSI Driver]
13
        WL1[Workload 1]
14
        WL2[Workload 2]
15

16
        SA1 --> CSI1
17
        CSI1 --> WL1
18
        CSI1 --> WL2
19
    end
20

21
    subgraph "Worker Node 2"
22
        SA2[SPIRE Agent]
23
        CSI2[SPIFFE CSI Driver]
24
        WL3[Workload 3]
25
        WL4[Workload 4]
26

27
        SA2 --> CSI2
28
        CSI2 --> WL3
29
        CSI2 --> WL4
30
    end
31

32
    SA1 -.->|Node Attestation| SS
33
    SA2 -.->|Node Attestation| SS
34
    WL1 -.->|Workload API| SA1
35
    WL2 -.->|Workload API| SA1
36
    WL3 -.->|Workload API| SA2
37
    WL4 -.->|Workload API| SA2

Core Components#

SPIRE Server: Central authority that issues SPIFFE IDs and manages trust bundles
SPIRE Agent: Runs on each node, performs workload attestation
SPIFFE CSI Driver: Mounts the Workload API socket into pods
Registration Entries: Define which workloads get which identities

Prerequisites#

Before we begin, ensure you have:

1
# Kubernetes cluster (1.19+)
2
kubectl version --short
3

4
# Helm 3
5
helm version --short
6

7
# cert-manager (for TLS certificates)
8
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.3/cert-manager.yaml
9

10
# Verify cert-manager is ready
11
kubectl wait --for=condition=ready --timeout=300s -n cert-manager pod -l app.kubernetes.io/instance=cert-manager

Step 1: Install SPIRE Using Helm#

First, let’s add the SPIFFE Helm repository and install SPIRE:

1
# Add SPIFFE Helm repository
2
helm repo add spiffe https://spiffe.github.io/helm-charts-hardened/
3
helm repo update
4

5
# Create namespace
6
kubectl create namespace spire-system
7

8
# Install SPIRE with production-ready configuration
9
cat <<EOF > spire-values.yaml
10
global:
11
  spire:
12
    # Your trust domain - change this!
13
    trustDomain: "prod.example.com"
14
    # Bundle endpoint for federation
15
    bundleEndpoint:
16
      address: "0.0.0.0"
17
      port: 8443
18

19
spire-server:
20
  # High availability configuration
21
  replicaCount: 1  # Increase for HA
22

23
  controllerManager:
24
    enabled: true
25

26
  nodeAttestor:
27
    k8sPsat:
28
      enabled: true
29

30
  dataStore:
31
    sql:
32
      databaseType: sqlite3
33
      connectionString: "/run/spire/data/datastore.sqlite3"
34

35
  # For production, use PostgreSQL:
36
  # dataStore:
37
  #   sql:
38
  #     databaseType: postgres
39
  #     connectionString: "dbname=spire user=spire host=postgres password=\${DBPASSWORD}"
40

41
  keyManager:
42
    disk:
43
      enabled: true
44

45
  upstreamAuthority:
46
    disk:
47
      enabled: true
48
      cert: "/run/spire/ca/ca.crt"
49
      key: "/run/spire/ca/ca.key"
50

51
  ca:
52
    subject:
53
      country: ["US"]
54
      organization: ["Example Corp"]
55
      commonName: "SPIRE Server CA"
56

57
spire-agent:
58
  # Run on all nodes
59
  nodeSelector: {}
60

61
  server:
62
    address: "spire-server.spire-system"
63
    port: 8081
64

65
  # Enable Workload API for all pods
66
  socketPath: "/run/spire/agent-sockets/spire-agent.sock"
67

68
  # Health checks
69
  healthChecks:
70
    enabled: true
71
    port: 9982
72

73
# SPIFFE CSI Driver
74
spiffe-csi-driver:
75
  enabled: true
76

77
# SPIFFE OIDC Discovery Provider
78
spiffe-oidc-discovery-provider:
79
  enabled: true
80

81
  config:
82
    domains:
83
      - "oidc-discovery.example.com"
84
EOF
85

86
# Install SPIRE
87
helm upgrade --install spire spiffe/spire \
88
  --namespace spire-system \
89
  --values spire-values.yaml \
90
  --wait

Step 2: Verify SPIRE Installation#

Let’s verify that SPIRE is running correctly:

1
# Check pods
2
kubectl get pods -n spire-system
3

4
# Expected output:
5
# NAME                                READY   STATUS    RESTARTS   AGE
6
# spire-server-0                      2/2     Running   0          2m
7
# spire-agent-xxxxx                   1/1     Running   0          2m
8
# spiffe-csi-driver-xxxxx             1/1     Running   0          2m
9
# spiffe-oidc-discovery-provider-xxx  1/1     Running   0          2m
10

11
# Check SPIRE Server health
12
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
13
  /opt/spire/bin/spire-server healthcheck
14

15
# Check SPIRE Agent health on a node
16
kubectl exec -n spire-system -it $(kubectl get pods -n spire-system -l app=spire-agent -o jsonpath='{.items[0].metadata.name}') -- \
17
  /opt/spire/bin/spire-agent healthcheck

Step 3: Configure Workload Registration#

Now let’s register workloads. We’ll use the Kubernetes Workload Registrar for automatic registration:

1
apiVersion: spire.spiffe.io/v1alpha1
2
kind: ClusterSPIFFEID
3
metadata:
4
  name: default-workloads
5
spec:
6
  # SPIFFE ID template
7
  spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
8

9
  # Pod selector
10
  podSelector:
11
    matchLabels:
12
      spiffe: "enabled"
13

14
  # Workload selector for the agent
15
  workloadSelectorTemplates:
16
    - "k8s:ns:{{ .PodMeta.Namespace }}"
17
    - "k8s:sa:{{ .PodSpec.ServiceAccountName }}"
18

19
  # Optional: DNS names for the SVID
20
  dnsNameTemplates:
21
    - "{{ .PodMeta.Name }}.{{ .PodMeta.Namespace }}.svc.cluster.local"
22

23
  # TTL for the SVID
24
  ttl: 3600
25
---
26
# More specific registration for critical workloads
27
apiVersion: spire.spiffe.io/v1alpha1
28
kind: ClusterSPIFFEID
29
metadata:
30
  name: database-workloads
31
spec:
32
  spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}/{{ .PodMeta.Name }}"
33

34
  namespaceSelector:
35
    matchNames:
36
      - "production"
37
      - "staging"
38

39
  podSelector:
40
    matchLabels:
41
      app: "postgresql"
42

43
  workloadSelectorTemplates:
44
    - "k8s:ns:{{ .PodMeta.Namespace }}"
45
    - "k8s:sa:{{ .PodSpec.ServiceAccountName }}"
46
    - "k8s:pod-name:{{ .PodMeta.Name }}"
47

48
  # Federates with these trust domains
49
  federatesWith:
50
    - "partner.example.com"
51
    - "cloud.example.com"

Apply the registration:

1
kubectl apply -f workload-registration.yaml

Step 4: Deploy a Sample Application with SPIFFE Identity#

Let’s deploy a sample application that uses SPIFFE identities:

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: frontend
5
  namespace: default
6
---
7
apiVersion: v1
8
kind: ServiceAccount
9
metadata:
10
  name: backend
11
  namespace: default
12
---
13
apiVersion: apps/v1
14
kind: Deployment
15
metadata:
16
  name: frontend
17
  namespace: default
18
spec:
19
  replicas: 1
20
  selector:
21
    matchLabels:
22
      app: frontend
23
  template:
24
    metadata:
25
      labels:
26
        app: frontend
27
        spiffe: enabled
28
    spec:
29
      serviceAccountName: frontend
30
      containers:
31
        - name: frontend
32
          image: spiffe/spire-examples:latest
33
          command: ["/opt/spire-examples/spiffe-workload"]
34
          env:
35
            - name: SPIFFE_ENDPOINT_SOCKET
36
              value: "unix:///spiffe-workload-api/spire-agent.sock"
37
          volumeMounts:
38
            - name: spiffe-workload-api
39
              mountPath: /spiffe-workload-api
40
              readOnly: true
41
      volumes:
42
        - name: spiffe-workload-api
43
          csi:
44
            driver: "csi.spiffe.io"
45
            readOnly: true
46
---
47
apiVersion: apps/v1
48
kind: Deployment
49
metadata:
50
  name: backend
51
  namespace: default
52
spec:
53
  replicas: 1
54
  selector:
55
    matchLabels:
56
      app: backend
57
  template:
58
    metadata:
59
      labels:
60
        app: backend
61
        spiffe: enabled
62
    spec:
63
      serviceAccountName: backend
64
      containers:
65
        - name: backend
66
          image: spiffe/spire-examples:latest
67
          command: ["/opt/spire-examples/spiffe-workload"]
68
          env:
69
            - name: SPIFFE_ENDPOINT_SOCKET
70
              value: "unix:///spiffe-workload-api/spire-agent.sock"
71
          volumeMounts:
72
            - name: spiffe-workload-api
73
              mountPath: /spiffe-workload-api
74
              readOnly: true
75
      volumes:
76
        - name: spiffe-workload-api
77
          csi:
78
            driver: "csi.spiffe.io"
79
            readOnly: true

Deploy the application:

1
kubectl apply -f sample-app.yaml
2

3
# Wait for pods to be ready
4
kubectl wait --for=condition=ready pod -l app=frontend --timeout=60s
5
kubectl wait --for=condition=ready pod -l app=backend --timeout=60s

Step 5: Verify Workload Identity#

Let’s verify that our workloads have received their SPIFFE identities:

1
# Check frontend identity
2
kubectl exec -it $(kubectl get pod -l app=frontend -o jsonpath='{.items[0].metadata.name}') -- \
3
  /opt/spire-examples/spiffe-workload get-svid
4

5
# Expected output:
6
# SPIFFE ID: spiffe://prod.example.com/ns/default/sa/frontend
7
# SVID Valid After: 2025-01-27 10:00:00 +0000 UTC
8
# SVID Valid Until: 2025-01-27 11:00:00 +0000 UTC
9
# CA #1 Valid After: 2025-01-27 00:00:00 +0000 UTC
10
# CA #1 Valid Until: 2026-01-27 00:00:00 +0000 UTC
11

12
# Check backend identity
13
kubectl exec -it $(kubectl get pod -l app=backend -o jsonpath='{.items[0].metadata.name}') -- \
14
  /opt/spire-examples/spiffe-workload get-svid

Step 6: Implement mTLS Between Workloads#

Now let’s implement mutual TLS between our workloads using SPIFFE identities:

1
// mtls-client.go - Frontend calling Backend
2
package main
3

4
import (
5
    "context"
6
    "crypto/tls"
7
    "fmt"
8
    "io"
9
    "net/http"
10

11
    "github.com/spiffe/go-spiffe/v2/spiffeid"
12
    "github.com/spiffe/go-spiffe/v2/spiffetls"
13
    "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig"
14
    "github.com/spiffe/go-spiffe/v2/workloadapi"
15
)
16

17
func main() {
18
    ctx := context.Background()
19

20
    // Create a Workload API client
21
    client, err := workloadapi.New(ctx, workloadapi.WithAddr("unix:///spiffe-workload-api/spire-agent.sock"))
22
    if err != nil {
23
        panic(err)
24
    }
25
    defer client.Close()
26

27
    // Create TLS config for mTLS
28
    backendID := spiffeid.Must("prod.example.com", "ns", "default", "sa", "backend")
29
    tlsConfig := tlsconfig.MTLSClientConfig(client, client, tlsconfig.AuthorizeID(backendID))
30

31
    // Create HTTP client with SPIFFE TLS
32
    httpClient := &http.Client{
33
        Transport: &http.Transport{
34
            TLSClientConfig: tlsConfig,
35
        },
36
    }
37

38
    // Make authenticated request
39
    resp, err := httpClient.Get("https://backend.default.svc.cluster.local:8443/api/data")
40
    if err != nil {
41
        panic(err)
42
    }
43
    defer resp.Body.Close()
44

45
    body, _ := io.ReadAll(resp.Body)
46
    fmt.Printf("Response: %s\n", body)
47
}

1
// mtls-server.go - Backend server
2
package main
3

4
import (
5
    "context"
6
    "fmt"
7
    "net/http"
8

9
    "github.com/spiffe/go-spiffe/v2/spiffeid"
10
    "github.com/spiffe/go-spiffe/v2/spiffetls"
11
    "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig"
12
    "github.com/spiffe/go-spiffe/v2/workloadapi"
13
)
14

15
func main() {
16
    ctx := context.Background()
17

18
    // Create Workload API client
19
    client, err := workloadapi.New(ctx, workloadapi.WithAddr("unix:///spiffe-workload-api/spire-agent.sock"))
20
    if err != nil {
21
        panic(err)
22
    }
23
    defer client.Close()
24

25
    // Create TLS config that only accepts frontend
26
    frontendID := spiffeid.Must("prod.example.com", "ns", "default", "sa", "frontend")
27
    tlsConfig := tlsconfig.MTLSServerConfig(client, client, tlsconfig.AuthorizeID(frontendID))
28

29
    // Create HTTPS server
30
    server := &http.Server{
31
        Addr:      ":8443",
32
        TLSConfig: tlsConfig,
33
        Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
34
            // Extract peer identity
35
            if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
36
                id, err := spiffeid.FromURI(r.TLS.PeerCertificates[0].URIs[0])
37
                if err == nil {
38
                    fmt.Fprintf(w, "Hello %s! Here's your secure data.\n", id)
39
                    return
40
                }
41
            }
42
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
43
        }),
44
    }
45

46
    fmt.Println("Server listening on :8443...")
47
    if err := server.ListenAndServeTLS("", ""); err != nil {
48
        panic(err)
49
    }
50
}

Step 7: Advanced Configuration#

High Availability Setup#

For production environments, configure SPIRE Server for high availability:

1
spire-server:
2
  replicaCount: 3
3

4
  dataStore:
5
    sql:
6
      databaseType: postgres
7
      connectionString: "host=postgres-ha.data.svc.cluster.local dbname=spire user=spire sslmode=require"
8

9
  notifier:
10
    k8sbundle:
11
      enabled: true
12
      namespace: "spire-system"
13

14
  # Anti-affinity for spreading across nodes
15
  affinity:
16
    podAntiAffinity:
17
      requiredDuringSchedulingIgnoredDuringExecution:
18
        - labelSelector:
19
            matchExpressions:
20
              - key: app
21
                operator: In
22
                values:
23
                  - spire-server
24
          topologyKey: kubernetes.io/hostname

Federation Configuration#

To enable federation between trust domains:

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: spire-federation
5
  namespace: spire-system
6
data:
7
  federation.conf: |
8
    federates_with {
9
      "partner.example.com" {
10
        bundle_endpoint_address = "spire-bundle.partner.example.com"
11
        bundle_endpoint_port = 8443
12
        bundle_endpoint_spiffe_id = "spiffe://partner.example.com/spire/server"
13
      }
14
    }

Custom Node Attestor#

For cloud environments, use platform-specific attestors:

1
# AWS node attestor
2
spire-server:
3
  nodeAttestor:
4
    aws_iid:
5
      enabled: true
6
      access_key_id: "${AWS_ACCESS_KEY_ID}"
7
      secret_access_key: "${AWS_SECRET_ACCESS_KEY}"
8
      skip_block_device: true
9

10
spire-agent:
11
  nodeAttestor:
12
    aws_iid:
13
      enabled: true
14

15
# GCP node attestor
16
spire-server:
17
  nodeAttestor:
18
    gcp_iit:
19
      enabled: true
20
      projectid_allow_list: ["my-project-1", "my-project-2"]
21

22
spire-agent:
23
  nodeAttestor:
24
    gcp_iit:
25
      enabled: true

Step 8: Integration with Service Mesh#

Istio Integration#

To use SPIRE as Istio’s certificate provider:

1
# Install Istio with custom CA
2
istioctl install --set values.pilot.env.EXTERNAL_CA=ISTIOD_RA_KUBERNETES_API \
3
  --set values.global.caAddress=spire-server.spire-system.svc:8081 \
4
  --set values.global.meshID=spiffe://prod.example.com \
5
  --set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION=true

Linkerd Integration#

For Linkerd, configure the identity issuer:

1
apiVersion: cert-manager.io/v1
2
kind: Certificate
3
metadata:
4
  name: linkerd-identity-issuer
5
  namespace: linkerd
6
spec:
7
  secretName: linkerd-identity-issuer
8
  duration: 48h
9
  renewBefore: 25h
10
  issuerRef:
11
    name: spire-ca
12
    kind: ClusterIssuer
13
  commonName: identity.linkerd.cluster.local
14
  dnsNames:
15
    - identity.linkerd.cluster.local
16
  isCA: true
17
  privateKey:
18
    algorithm: ECDSA
19
  usages:
20
    - cert sign
21
    - crl sign
22
    - server auth
23
    - client auth

Step 9: Monitoring and Observability#

Configure Prometheus metrics for SPIRE:

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: prometheus-config
5
  namespace: monitoring
6
data:
7
  prometheus.yml: |
8
    scrape_configs:
9
    - job_name: 'spire-server'
10
      static_configs:
11
      - targets: ['spire-server.spire-system:9988']
12
      metric_relabel_configs:
13
      - source_labels: [__name__]
14
        regex: 'spire_server_.*'
15
        action: keep
16

17
    - job_name: 'spire-agent'
18
      kubernetes_sd_configs:
19
      - role: pod
20
        namespaces:
21
          names: ['spire-system']
22
      relabel_configs:
23
      - source_labels: [__meta_kubernetes_pod_label_app]
24
        regex: spire-agent
25
        action: keep
26
      - source_labels: [__meta_kubernetes_pod_ip]
27
        target_label: __address__
28
        replacement: '${1}:9988'

Step 10: Production Best Practices#

Security Hardening#

Network Policies: Restrict SPIRE Server access

1
apiVersion: networking.k8s.io/v1
2
kind: NetworkPolicy
3
metadata:
4
  name: spire-server-ingress
5
  namespace: spire-system
6
spec:
7
  podSelector:
8
    matchLabels:
9
      app: spire-server
10
  policyTypes:
11
    - Ingress
12
  ingress:
13
    - from:
14
        - namespaceSelector:
15
            matchLabels:
16
              name: spire-system
17
        - podSelector:
18
            matchLabels:
19
              app: spire-agent
20
      ports:
21
        - protocol: TCP
22
          port: 8081

RBAC Configuration: Limit SPIRE permissions

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: spire-server-limited
5
rules:
6
  - apiGroups: [""]
7
    resources: ["nodes", "pods"]
8
    verbs: ["get", "list", "watch"]
9
  - apiGroups: ["authentication.k8s.io"]
10
    resources: ["tokenreviews"]
11
    verbs: ["create"]

Performance Tuning#

1
spire-server:
2
  resources:
3
    requests:
4
      memory: "512Mi"
5
      cpu: "100m"
6
    limits:
7
      memory: "2Gi"
8
      cpu: "1000m"
9

10
  # Cache configuration
11
  config:
12
    server:
13
      cache_size: 10000
14

15
spire-agent:
16
  resources:
17
    requests:
18
      memory: "128Mi"
19
      cpu: "50m"
20
    limits:
21
      memory: "512Mi"
22
      cpu: "500m"
23

24
  # Sync interval optimization
25
  config:
26
    agent:
27
      sync_interval: "10s"

Troubleshooting Common Issues#

Issue 1: Workload Not Receiving SVID#

1
# Check registration entries
2
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
3
  /opt/spire/bin/spire-server entry list
4

5
# Check agent logs
6
kubectl logs -n spire-system $(kubectl get pods -n spire-system -l app=spire-agent -o jsonpath='{.items[0].metadata.name}')
7

8
# Verify CSI driver
9
kubectl get csidriver csi.spiffe.io
10
kubectl get csinodes

Issue 2: Federation Not Working#

1
# Check bundle endpoint
2
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
3
  /opt/spire/bin/spire-server bundle show -format spiffe
4

5
# Test bundle endpoint connectivity
6
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
7
  curl -k https://localhost:8443/bundle

Issue 3: Performance Issues#

1
# Check metrics
2
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
3
  curl -s localhost:9988/metrics | grep spire_server_
4

5
# Analyze datastore performance
6
kubectl exec -n spire-system spire-server-0 -c spire-server -- \
7
  /opt/spire/bin/spire-server entry count

Migration from VM-Based SPIRE#

If you’re migrating from my VM-based SPIFFE/SPIRE setup, here are the key differences:

Node Attestation: Use Kubernetes PSAT instead of join tokens
Workload Attestation: Kubernetes selectors instead of Unix selectors
Registration: Automatic via CRDs instead of manual CLI
Scaling: Horizontal pod autoscaling instead of manual node addition
Storage: Consider managed databases instead of local SQLite

Migration checklist:

Export existing registration entries
Update SPIFFE ID structure for Kubernetes namespaces
Migrate trust bundles if keeping the same trust domain
Update workload code to use CSI driver paths
Test federation with existing infrastructure

Conclusion and Next Steps#

You now have a production-ready SPIFFE/SPIRE deployment on Kubernetes that provides:

✅ Cryptographic workload identities
✅ Automatic certificate rotation
✅ Zero-trust pod-to-pod communication
✅ Integration with Kubernetes primitives
✅ Foundation for service mesh adoption

In upcoming posts, we’ll explore:

Deep dive into SPIRE Controller Manager and CRDs
Multi-cluster federation patterns
Advanced attestation with TPM and cloud providers
Performance optimization for large-scale deployments
Integration with Istio and Linkerd service meshes

The journey from traditional PKI to cloud-native workload identity is complete. Your Kubernetes cluster now has a robust, scalable, and secure identity foundation ready for zero-trust networking.

Additional Resources#

Have questions or ran into issues? Feel free to reach out or check the SPIFFE Slack community for help.