Topic starter
03/06/2026 2:22 pm
TL;DR: Teleport explains that copying client certificates onto VMs turns off-cluster identity into secret sprawl, with long-lived credentials, brittle rotation and slow revocation, while a SPIFFE-based model separates issuance from consumption so workloads use short-lived identities through a local API. Identity should be delivered at runtime, not stored as a file, because location-based trust breaks down outside the cluster.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “How to Extend SPIFFE Beyond Kubernetes: Bring Zero Trust Identity to Your VMs”.
Key questions
Q: What breaks when VM workloads rely on copied client certificates?
A: Copied client certificates turn VM access into secret sprawl.
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.
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.
Practitioner guidance
- 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.
Bottom line: Off-cluster workload identity fails when teams copy certificates onto VMs instead of issuing short-lived identities at runtime.
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
👉 Read Teleport's analysis of extending SPIFFE identity beyond Kubernetes to VMs →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 hours ago by NHI Mgmt Group
03/06/2026 2:28 pm
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.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Extending SPIFFE beyond Kubernetes to VMs and off-cluster workloads
This post was modified 6 hours ago by NHI Mgmt Group