Module 8 of 13

SPIRE Integrations and Service Mesh

Connect SPIRE with Envoy, Istio, and the cloud-native ecosystem

3.5 hours3 labsFree

Start here

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
SPIRE + SERVICE MESH INTEGRATIONSPIRE ServerIdentity AuthorityPod AApp (HTTP)Envoy SidecarSVID from SPIRESPIRE Agent (Workload API)Pod BApp (HTTP)Envoy SidecarSVID from SPIRESPIRE Agent (Workload API)mTLS

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

Where this shows up

  • 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

Keep these close

  • 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

What usually breaks

  • 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

Alternatives

Other production approaches

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).

Key terms

Vocabulary used in this module

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)

Labs

Hands-on labs

SPIRE with Envoy mTLS

Configure Envoy to use SPIRE for automatic mTLS.

  1. Deploy Envoy sidecars alongside application pods
  2. Configure Envoy SDS to use the SPIRE Workload API
  3. Verify mTLS between Envoy sidecars
  4. Observe certificate rotation in Envoy admin interface
View lab on GitHub

SPIRE + OPA Authorization

Combine SPIRE identity with OPA policy enforcement via Envoy.

  1. Deploy OPA alongside Envoy
  2. Write Rego policies that reference SPIFFE IDs
  3. Configure Envoy ext_authz filter
  4. Test that only authorized services can access protected endpoints
View lab on GitHub

OIDC Discovery with SPIRE

Configure SPIRE as an OIDC provider for JWT verification.

  1. Enable OIDC discovery on SPIRE Server
  2. Fetch the OIDC discovery document
  3. Verify a JWT-SVID using the OIDC public keys
  4. Integrate with an API gateway that supports OIDC
View lab on GitHub

Recap

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

Related resources

Keep learning across CodersSecret