Edge Kubernetes clusters present a certificate management problem that cloud deployments often sidestep: you have dozens of short-lived workloads across geographically distributed nodes, no reliable connection to a central certificate authority, and IoT devices that need to authenticate to services without embedding static credentials. Static API keys and long-lived certificates are the common workaround — and they are also how edge deployments accumulate credential sprawl that becomes a security liability over time.

SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE (SPIFFE Runtime Environment) solve this by automating workload identity using short-lived X.509 certificates that rotate automatically, without requiring a human to issue, distribute, or renew them.

What SPIFFE Defines

SPIFFE is a CNCF standard that specifies:

  • SPIFFE ID: A URI-format identifier for a workload, e.g. spiffe://example.org/edge/sensor-processor. The identifier encodes the trust domain and workload name, not the IP or hostname.
  • SVID (SPIFFE Verifiable Identity Document): A credential that proves a workload’s identity. SPIFFE defines two SVID types: X.509-SVID (a certificate with the SPIFFE ID in the Subject Alternative Name) and JWT-SVID (a signed JWT token).
  • Trust bundle: A set of CA certificates that establish trust within and between SPIFFE trust domains.
  • Workload API: A local API that workloads call to obtain their current SVIDs and the trust bundle, without needing credentials to authenticate to the API itself.

The Workload API is available only within the workload’s execution environment (via a Unix socket), so it cannot be called remotely. A process running on the node can get its certificate; a process from outside cannot impersonate it.

What SPIRE Adds

SPIRE is the production implementation of the SPIFFE specification, providing:

  • SPIRE Server: The certificate authority and policy engine. Maintains the SPIFFE trust domain, issues X.509-SVIDs to attested workloads, and manages trust bundle federation.
  • SPIRE Agent: Runs on every node (as a DaemonSet in Kubernetes). Attests the node’s identity to the SPIRE Server, then attests workloads running on that node and issues them SVIDs via the local Workload API.
  • Node attestation plugins: SPIRE verifies node identity through platform-specific mechanisms — Kubernetes JWTS for cloud Kubernetes, TPM attestation for edge hardware, or AWS/GCP instance identity documents.
  • Workload attestation plugins: SPIRE identifies workloads by their Kubernetes attributes (namespace, service account, pod labels) or Unix process properties (UID, GID, binary path).

The flow is:

[Workload] → Workload API (Unix socket) → [SPIRE Agent]
                                                ↓
                                          Attest workload
                                          (check pod namespace/SA)
                                                ↓
                                          Request SVID from SPIRE Server
                                                ↓
                                          Issue X.509-SVID (1h TTL)
                                                ↓
                                          Return SVID to workload

The certificate has a short TTL (typically 1 hour). SPIRE Agent automatically rotates it before expiry. The workload never handles long-lived credentials.

Installing SPIRE on Kubernetes

# Deploy SPIRE using the Helm chart
helm repo add spiffe https://spiffe.github.io/helm-charts-hardened/
helm repo update

helm install spire-crds spiffe/spire-crds --namespace spire-system --create-namespace
helm install spire spiffe/spire --namespace spire-system

The default installation deploys one SPIRE Server and a SPIRE Agent DaemonSet that runs on every node.

Registering Workloads

SPIRE uses registration entries to define which workloads get which SPIFFE IDs. For a Kubernetes deployment:

# Register the sensor processor service
kubectl exec -n spire-system deploy/spire-server -- \
  /opt/spire/bin/spire-server entry create \
  -spiffeID spiffe://edge.example.org/sensor-processor \
  -parentID spiffe://edge.example.org/spire/agent/k8s_sat/edge-node-01 \
  -selector k8s:ns:iot-system \
  -selector k8s:sa:sensor-processor \
  -ttl 3600

This entry says: workloads in namespace iot-system running under service account sensor-processor receive the SPIFFE ID spiffe://edge.example.org/sensor-processor. The TTL is 3600 seconds (1 hour).

Consuming SVIDs in Workloads

Go SDK

package main

import (
    "context"
    "crypto/tls"
    "log"
    
    "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig"
    "github.com/spiffe/go-spiffe/v2/workloadapi"
)

func main() {
    ctx := context.Background()
    
    // Connect to Workload API — no credentials needed
    source, err := workloadapi.NewX509Source(ctx)
    if err != nil {
        log.Fatalf("failed to get X.509 source: %v", err)
    }
    defer source.Close()

    // Create TLS config that automatically uses the SVID and validates peer SPIFFEIDs
    tlsConfig := tlsconfig.MTLSClientConfig(source, source, tlsconfig.AuthorizeID(
        spiffeid.RequireIDFromString("spiffe://edge.example.org/data-store"),
    ))

    // Make mTLS requests to the data store — both sides present SPIFFE certificates
    client := &http.Client{Transport: &http.Transport{TLSClientConfig: tlsConfig}}
    resp, err := client.Get("https://data-store.iot-system.svc.cluster.local/readings")
}

The Go SPIFFE SDK automatically fetches the current SVID and trust bundle from the local Workload API socket and rotates certificates transparently. The application code does not handle certificate files or renewal.

Environment Variable Injection (Envoy / Service Mesh)

For workloads that use Envoy or a compatible proxy sidecar, SPIRE can inject SVIDs via the SDS (Secret Discovery Service) API. Envoy fetches its certificate from SPIRE Agent rather than a file, and mTLS between all services in the mesh is automatic without modifying application code.

# Envoy cluster configuration using SPIRE SDS
static_resources:
  clusters:
  - name: data-store
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        common_tls_context:
          tls_certificate_sds_secret_configs:
          - name: "spiffe://edge.example.org/sensor-processor"
            sds_config:
              api_config_source:
                api_type: GRPC
                grpc_services:
                - envoy_grpc:
                    cluster_name: spire_agent

SPIRE on k3s Edge Clusters

SPIRE runs on k3s with minor configuration changes for the lightweight runtime. The primary difference is node attestation: edge nodes often lack cloud provider metadata endpoints, so SPIRE uses k8s_sat (Kubernetes service account token) attestation or tpm attestation for nodes with TPM hardware.

# SPIRE Server config for edge k3s with SAT attestation
NodeAttestor "k8s_sat" {
    plugin_data {
        clusters = {
            "edge-cluster" = {
                use_token_review_api_validation = true
                service_account_allow_list = ["spire-system:spire-agent"]
            }
        }
    }
}

For IoT gateways running k3s on ARM hardware with TPM 2.0 chips (common in industrial edge devices), TPM attestation provides hardware-rooted node identity that cannot be replicated without physical access to the device.

Federation Between Edge and Cloud SPIRE Instances

In architectures where edge clusters report to a central cloud cluster, SPIRE federation allows workloads in different trust domains to authenticate to each other. The edge cluster’s SPIRE Server federates with the cloud SPIRE Server, and workloads on each side can validate certificates issued by the other:

# Create federation relationship between edge and cloud
spire-server federation create \
  --bundleEndpointURL https://cloud-spire.example.org:8443 \
  --bundleEndpointProfile https_spiffe \
  --trustDomain cloud.example.org

This enables a sensor on an edge cluster to authenticate to a cloud ingestion API without sharing long-lived credentials across the WAN link.

Practical Impact for IoT Security

The conventional approach to authenticating IoT workloads to services — static API keys embedded in environment variables, long-lived TLS client certificates, or shared secrets in ConfigMaps — accumulates security debt over time. Keys expire or are forgotten. Certificate renewals are manual and missed. Secrets in environment variables appear in logs.

SPIRE’s automatic rotation means every service-to-service connection uses a certificate issued within the last hour, cryptographically bound to the specific workload identity. Compromising a running workload’s certificate is only useful for that hour. There are no long-lived credentials to extract and reuse.

For IoT pipelines where sensor data flows through multiple processing stages, SPIFFE mTLS gives you a continuous chain of identity from sensor gateway to cloud store — every hop authenticated, every certificate short-lived and automatically renewed.

References