Extending SPIFFE beyond Kubernetes to VMs and off-cluster workloads

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: Extending SPIFFE to VMs and other off-cluster workloads requires separating identity issuance from identity consumption so teams avoid long-lived credentials and secret sprawl.

Why it matters: IAM and NHI teams need this pattern because VM identity governance fails when certificates are copied around like files instead of being issued and consumed as short-lived workload identities.

👉 Read Teleport's analysis of extending SPIFFE identity beyond Kubernetes to VMs

Context

Off-cluster identity becomes harder to govern when teams treat workload credentials as something to copy onto a VM rather than something to issue on demand. In practice, that creates a security gap between Kubernetes-native workload identity and the reality of VMs, edge gateways, and legacy services that still need to call protected services.

The article frames SPIFFE as the identity layer that closes that gap by giving software workloads a verifiable identity instead of relying on IP-based trust or shared certificates. For identity programmes, the issue is not just technical compatibility with VMs. It is whether lifecycle control, revocation, and auditability remain intact once workloads move outside the cluster boundary.

Key questions

Q: What breaks when VM workloads rely on copied client certificates?

A: Copied client certificates turn VM access into secret sprawl. The credential can outlive the workload, rotation becomes manual and brittle, and revocation slows down. That creates an NHI governance problem because the identity is no longer bound to a short-lived lifecycle, so auditability and offboarding both weaken.

Q: Why do off-cluster workloads make zero trust harder to sustain?

A: Zero trust depends on verifiable, runtime identity, not network location or shared certificates. Once workloads move to VMs or edge systems, IP-based trust and cluster-local assumptions stop being reliable. The programme has to govern the principal that is presenting access, not the host that happens to carry it.

Q: How do teams know whether workload identity is still being governed well?

A: Look for short-lived issuance, automated rotation, and revocation that completes without manual certificate handling. If credentials are copied to hosts, stored on disk, or rotated by ad hoc procedures, governance is already slipping from runtime control into secret management debt.

Q: What is the difference between cluster-local CA trust and portable SPIFFE trust?

A: Cluster-local CA trust is tied to one Kubernetes control plane, so identity is constrained by that environment’s lifecycle. Portable SPIFFE trust gives the workload a consistent principal across clusters and VMs, which makes cross-environment policy and revocation much easier to standardise.

Technical breakdown

Why copied VM certificates become secret sprawl

When a client certificate is copied onto a VM, the credential becomes detached from the workload lifecycle. That creates long-lived secrets, manual rotation burden, and delayed revocation, which are classic NHI governance failures. The problem is not simply storage on disk. It is that the identity is no longer bound to a short-lived issuance model, so the workload can outlive the credential and the credential can outlive the workload. In a multi-environment setup, that also creates confusion when teams fall back to IP rules or shared certificates for authorization.

Practical implication: treat copied certificates on VMs as an offboarding and rotation failure, not just a deployment shortcut.

How separation of issuance and consumption changes workload identity

The architectural shift here is to let a trusted authority issue a short-lived SPIFFE identity while the workload consumes it locally through an API or socket. That matters because private keys do not need to be distributed as files, and the workload can rotate identities without human handling. In the Teleport pattern described, Envoy retrieves identity through SDS from a local Workload API, while the trust chain is managed centrally. This preserves a clear boundary between issuing identity and presenting identity, which is what makes runtime delivery scalable across Kubernetes and VMs.

Practical implication: design workload identity so retrieval and use happen separately, with no static private key copied to the host.

Why cluster-local CAs do not scale cleanly to off-cluster resources

A cluster-local CA works well when identity stays inside Kubernetes, but it becomes brittle when the trust anchor is locked to one control plane. Off-cluster callers then inherit cluster lifecycle risk, including upgrades, reinstallations, and trust-chain changes that can disrupt mTLS. That is why a shared trust domain matters. It makes VMs, clusters, and other workloads consume the same identity model rather than each environment inventing its own trust boundary. For practitioners, the question is whether their current CA model supports consistent policy across environments or silently fragments it.

Practical implication: validate whether your trust anchor can span VMs and clusters without forcing per-environment identity exceptions.

Threat narrative

Attacker objective: The practical attacker objective in this pattern is to preserve usable access through credentials that outlive the workload and remain difficult to revoke.

1. Entry occurs when teams copy a client certificate onto a VM so the workload can reach a Kubernetes service, creating a static credential outside the normal workload lifecycle.
2. Credential exposure follows because the certificate can persist after the workload changes, making revocation and rotation slower and less reliable than short-lived issuance.
3. Impact is governance drift: access decisions degrade into shared certificates or IP-based rules, which weakens auditability and turns off-cluster access into secret sprawl.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• Twitch breach 2021: A server misconfiguration leaked Twitch source code and payouts; the repositories held nearly 6,600 secrets, including 194 AWS keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Copied certificates on VMs are a governance failure, not a portability feature. The article describes a pattern where off-cluster workloads are secured by moving client certificates onto the VM, but that design breaks the lifecycle assumptions behind NHI governance. Long-lived credentials, brittle rotation, and slow revocation are not side effects. They are the result of treating workload identity as a file distribution problem rather than an issuance problem. Practitioners should read that as a control boundary failure, not an implementation convenience.

Identity issuance and identity consumption should not be the same control plane. Separating the two creates a cleaner operating model for SPIFFE identities across Kubernetes and VMs. That separation is the difference between a workload presenting a short-lived identity at runtime and a platform team managing credential artefacts by hand. The implication is that workload identity governance has to be designed around runtime presentation, not static storage.

Location-based trust is too weak for cross-environment workload access. The article shows why IP rules and cluster-local assumptions become brittle once identity leaves Kubernetes. A VM is still a workload, but it is governed differently from a pod because its trust anchor, rotation path, and operational ownership are not the same. Identity policy should follow the workload principal, not the host address.

VM identity governance now depends on the same standards thinking that already shaped Kubernetes identity. SPIFFE gives practitioners a portable identity primitive, but the real lesson is organisational: teams need one model for issuance, rotation, and revocation across clusters, VMs, and edge workloads. That is the direction the market is moving, and it will expose every programme still relying on environment-specific exceptions.

Ephemeral credential trust debt: the longer a workload credential survives outside the workload that needs it, the more governance debt accumulates. This article’s core contribution is to show that the debt is created by the delivery model itself, not by the workload type. The practitioner conclusion is simple: if the credential can outlive the workload, the control model is already behind.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Guide to SPIFFE and SPIRE

What this signals

Portable workload identity is becoming the real control plane for mixed Kubernetes and VM estates. Teams that still treat certificates as deployable files will keep fighting rotation, revocation, and audit problems each time a workload moves outside the cluster. The shift to short-lived identity delivered at runtime changes that calculus by making the workload principal, not the host, the unit of governance.

Identity delivery is now the architectural decision that determines whether zero trust scales beyond Kubernetes. The pattern in this article shows why workload identity has to be issued and consumed separately if teams want a consistent policy model across clusters and VMs. That is the practical boundary between a portable trust model and a fragmented secret-management programme.

For practitioners

• Audit VM certificate delivery paths Map every off-cluster workload that currently receives a copied client certificate, then identify where the credential is stored, who rotates it, and how revocation is handled.
• Move workload identity to local issuance Use short-lived SPIFFE identities consumed through a local API or socket so the workload never depends on a private key file on disk.
• Separate trust anchors from cluster boundaries Verify that the trust chain can span Kubernetes and VM workloads without forcing per-cluster identity exceptions or manual federation workarounds.
• Replace IP-based access checks with workload principals Write authorization policies around SPIFFE identities so access follows the workload principal instead of the host address or shared certificate.

Key takeaways

• Off-cluster workload identity fails when teams copy certificates onto VMs instead of issuing short-lived identities at runtime.
• The article shows that secret sprawl, brittle rotation, and slow revocation are symptoms of the delivery model, not just poor operations.
• Practitioners should govern workload principals and trust chains across environments so VM identity does not become a separate exception path.

Key terms

• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Spiffe Svid: A SPIFFE Verifiable Identity Document is the short-lived cryptographic credential a workload uses to prove who it is. In this context, it matters because the identity must be issued and consumed without forcing the workload to store a private key as a file or depend on a long-lived certificate.
• Trust Chain: The trust chain is the set of delegated relationships that lets one system, token, or integration act on behalf of another. In NHI security, it is often the real attack surface because compromise travels through legitimate permissions instead of obvious malware.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full article

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

• Step-by-step Envoy, SDS, and Workload API flow for consuming SPIFFE identities on VMs
• The exact Istio AuthorizationPolicy example used to allow a specific VM principal
• Architecture notes on how Teleport anchors the trust chain across Kubernetes and VM workloads
• Implementation guidance for extending SPIFFE-based mTLS beyond the cluster boundary

👉 Teleport's full post covers the VM identity flow, trust-chain handling, and mesh policy example in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.