Module 8: SPIRE Integrations and Service Mesh

Learning Objectives

• Integrate SPIRE with Envoy as the identity provider
• Use SPIRE with Istio and Linkerd service meshes
• Configure OIDC discovery for JWT authentication
• Design SPIFFE ID naming schemas for production

Why This Matters

SPIRE in isolation is useful. SPIRE integrated with Envoy, Istio, and OPA is transformational. This module shows you how workload identity plugs into the broader cloud-native ecosystem — turning separate tools into a unified zero trust platform.

Lesson Content

SPIRE becomes most powerful when integrated with the cloud-native ecosystem. This module covers integration with Envoy (the most common sidecar proxy), Istio (the most popular service mesh), and OIDC discovery for JWT-based authentication.

SPIRE with Envoy

Envoy can use SPIRE as its certificate source via the Secret Discovery Service (SDS). Instead of loading certificates from files, Envoy requests them from the SPIRE Agent’s Workload API. This means automatic certificate rotation with zero Envoy restarts, mTLS between all Envoy sidecars, and SPIFFE ID extraction for authorization decisions.

SPIRE with Istio

Istio has its own certificate authority (istiod). But SPIRE can replace it for organizations that need consistent identity across mesh and non-mesh workloads, stronger attestation than Kubernetes service account tokens, SPIFFE federation across clusters, or integration with non-Kubernetes workloads (VMs, bare metal).

OIDC Discovery with SPIRE

SPIRE can act as an OIDC provider, allowing external systems to verify JWT-SVIDs using standard OIDC discovery. This enables cloud provider integration (AWS IAM roles for SPIFFE identities), API gateway authentication, and cross-platform identity verification.

SPIFFE ID Naming Schemas

# Production naming conventions:

# Kubernetes workloads:
spiffe://company.org/k8s/cluster-name/ns/namespace/sa/service-account

# VM workloads:
spiffe://company.org/vm/region/service-name

# CI/CD pipelines:
spiffe://company.org/cicd/github/repo-name/workflow

# Good practices:
# - Include environment (cluster name) in the path
# - Use service account as the identity, not pod name
# - Keep paths hierarchical for policy matching
# - Document the schema for your organization

Real-World Use Cases

• Envoy SDS — automatic mTLS certificate delivery without restarts
• Istio with SPIRE CA — stronger attestation than Istio default
• OIDC federation — external services verifying SPIFFE JWTs via standard OIDC
• API gateway authentication — verifying workload identity at the edge

Production Notes

• Envoy SDS integration means zero-downtime certificate rotation. Envoy watches the SPIRE socket and reloads certificates automatically.
• When replacing Istio CA with SPIRE, perform a gradual rollout — run both CAs during migration, then cut over.
• OIDC discovery must be accessible from wherever JWT verification happens (API gateways, cloud provider IAM).

Common Mistakes

• Configuring Envoy SDS with the wrong socket path
• Not testing OIDC discovery endpoint accessibility from external consumers
• Using Istio CA and SPIRE CA simultaneously without understanding precedence
• Designing SPIFFE ID paths that do not support your service mesh routing needs

Production Alternatives

• Istio built-in CA: Simpler setup but weaker attestation. No federation, no VM support, limited to Kubernetes service accounts.
• cert-manager: Good for static certificate management but no workload attestation, no automatic identity, no Workload API.
• Vault PKI: Strong secret management but identity is application-level, not infrastructure-level. Requires Vault tokens (another secret to manage).

Production Story

A fintech company migrating from Istio's built-in CA to SPIRE ran both CAs in parallel for 3 weeks. During this period, they discovered that 12 services had hardcoded certificate paths that bypassed Envoy SDS. These services silently fell back to unencrypted HTTP when Istio CA was disabled. The parallel run caught every misconfiguration before production cutover. Lesson: never do a big-bang CA migration. Run both systems simultaneously and verify every service.

Career Relevance

Service mesh expertise combined with SPIFFE knowledge is a rare and valuable skill set. Organizations deploying Istio, Linkerd, or Envoy at scale need engineers who understand how identity, encryption, and policy enforcement connect at the infrastructure layer.

Key Terms

SDS

Secret Discovery Service — Envoy protocol for dynamic certificate delivery

OIDC

OpenID Connect — standard for identity verification via JWT tokens

Service Mesh

Infrastructure layer handling service-to-service communication (Istio, Linkerd, Envoy)

Hands-On Labs

1. SPIRE with Envoy mTLS

   Configure Envoy to use SPIRE for automatic mTLS.

   • Deploy Envoy sidecars alongside application pods
   • Configure Envoy SDS to use the SPIRE Workload API
   • Verify mTLS between Envoy sidecars
   • Observe certificate rotation in Envoy admin interface

   View lab files on GitHub

2. SPIRE + OPA Authorization

   Combine SPIRE identity with OPA policy enforcement via Envoy.

   • Deploy OPA alongside Envoy
   • Write Rego policies that reference SPIFFE IDs
   • Configure Envoy ext_authz filter
   • Test that only authorized services can access protected endpoints

   View lab files on GitHub

3. OIDC Discovery with SPIRE

   Configure SPIRE as an OIDC provider for JWT verification.

   • Enable OIDC discovery on SPIRE Server
   • Fetch the OIDC discovery document
   • Verify a JWT-SVID using the OIDC public keys
   • Integrate with an API gateway that supports OIDC

   View lab files on GitHub

Key Takeaways

• Envoy SDS integration gives automatic mTLS with zero restarts
• SPIRE can replace Istio CA for stronger attestation and federation
• OIDC discovery enables external systems to verify SPIFFE JWTs
• SPIFFE ID naming schemas should be documented and hierarchical
• The combination of SPIRE + Envoy + OPA provides complete zero trust