SPIFFE beyond Kubernetes: what changes for VM identity governance?

TL;DR: Off-cluster workloads still need cryptographic identity, but copying client certificates onto VMs creates long-lived credentials, brittle rotation, and slow revocation, according to Teleport. Separating identity issuance from identity consumption shifts the model toward short-lived workload identity, reducing secret sprawl while preserving policy consistency across Kubernetes and VM environments.

NHIMG editorial — based on content published by Teleport: How to Extend SPIFFE Beyond Kubernetes: Bring Zero Trust Identity to Your VMs

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

Questions worth separating out

Q: How should security teams extend workload identity to VMs without creating secret sprawl?

A: Security teams should deliver short-lived workload identities through a local consumption path rather than copying certificates onto the VM.

Q: Why do VMs complicate SPIFFE-based zero trust architectures?

A: VMs complicate SPIFFE-based zero trust because they do not inherit Kubernetes control plane identity lifecycle by default.

Q: What breaks when workload identity is delivered as copied certificates?

A: Copied certificates create long-lived credentials that often outlast the workload that needed them.

Practitioner guidance

• Map every off-cluster credential path Identify where VM and legacy services still depend on copied certificates, shared secrets, or IP-based allow rules, then classify each path by rotation burden and revocation difficulty.
• Separate identity issuance from consumption Move workloads toward local consumption of short-lived identities through a workload API or proxy so private keys are never stored as files on the target system.
• Standardise policy on workload identity Write access rules against SPIFFE principals instead of network location so Kubernetes services and VM callers are governed by the same identity semantics.

What's in the full article

Teleport's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step architecture for issuing SPIFFE identities to VMs through a local workload API
• Envoy and SDS configuration detail for consuming short-lived identities without storing private keys on disk
• Istio AuthorizationPolicy examples that bind access to a specific SPIFFE principal
• Discussion of how Teleport maintains the trust chain across Kubernetes and non-Kubernetes environments

👉 Read Teleport's guide to extending SPIFFE identity beyond Kubernetes →

SPIFFE beyond Kubernetes: what changes for VM identity governance?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →