SPIFFE vs Cloud-Native Workload Identity: Portability, Trust Domains and When to Use Each

Every major cloud now gives workloads a keyless identity, but each one is scoped to that provider's trust boundary, so teams running across clouds, Kubernetes clusters and data centres end up with several identity systems that do not recognise each other. SPIFFE (Secure Production Identity Framework For Everyone) is an open standard for workload identity that is independent of any platform; cloud-native workload identity is the set of built-in mechanisms each provider offers, such as managed identities, pod identity and workload identity federation. This guide compares the two as approaches: how identity is issued and verified, what a trust domain means in each, how portable the identity is, and how they combine. It is for platform engineers, cloud security architects and IAM teams choosing a workload identity strategy. Cloud platforms are listed alphabetically. For SPIFFE and SPIRE internals see the SPIFFE and SPIRE Guide; for the cloud mechanisms see the Cloud Workload Identity Guide.

Key takeaways

• Both remove static secrets. SPIFFE and cloud-native identity each issue short-lived, automatically rotated credentials to a workload after the platform proves what it is, which addresses OWASP NHI7:2025 Long-Lived Secrets.
• The difference is who defines the trust boundary. Cloud-native identity lives inside the provider's account, project or tenant. A SPIFFE trust domain is defined by you and can span clouds, clusters and on-premises hosts.
• Cloud-native wins inside one cloud. It needs no extra infrastructure, integrates with the provider's IAM policies and audit logs, and the provider runs the issuer.
• SPIFFE wins for service-to-service identity across platforms. One identity format (a SPIFFE ID in an X.509 or JWT document) for mTLS and authorisation everywhere, at the cost of running and securing the issuing infrastructure.
• Most mature estates use both. Workloads authenticate to each other with SPIFFE and exchange SPIFFE credentials for cloud credentials through federation, so cloud APIs still see a native principal.

What each approach is

SPIFFE

SPIFFE is a set of open specifications, each marked Stable in the project's standards repository (checked November 2026). Its core parts are:

• SPIFFE ID: a URI of the form spiffe://trust-domain-name/path. The specification says valid IDs must use the spiffe scheme, include a non-zero trust domain name and must not include a query or fragment, and implementations must support IDs up to 2,048 bytes.
• SVID (SPIFFE Verifiable Identity Document): either an X.509-SVID, which must carry exactly one URI SAN holding the SPIFFE ID, or a JWT-SVID, which must contain aud and exp claims. The JWT-SVID specification strongly recommends a single audience to limit replay.
• Workload API: a local endpoint (typically a Unix domain socket) from which a workload fetches its SVIDs and trust bundles without holding any bootstrap secret.
• Trust bundle and federation: each trust domain publishes its signing keys as a bundle. Federation lets one trust domain fetch another's bundle from a bundle endpoint, using the https_web or https_spiffe profile.

SPIRE is the reference implementation. A SPIRE agent attests the node (plugins include aws_iid, azure_imds, azure_msi, gcp_iit, k8s_psat, tpm_devid and x509pop) and then attests each workload (plugins include k8s, unix, docker and systemd) before the server issues SVIDs. SPIRE server documentation lists defaults of 1 hour for X.509-SVIDs, 5 minutes for JWT-SVIDs and 24 hours for the signing CA.

Cloud-native workload identity

Each provider issues credentials to workloads it hosts, and offers federation to accept identity from outside.

• Amazon Web Services: IAM roles deliver temporary credentials to compute. EKS Pod Identity associates an IAM role with a Kubernetes service account in a namespace; a node agent on link-local address 169.254.170.23 serves credentials, and roles trust the service principal pods.eks.amazonaws.com. IAM Roles Anywhere gives workloads outside AWS temporary credentials when they present X.509 certificates issued by a CA registered as a trust anchor. See the EKS Identity Hardening Guide and AWS IAM Roles Anywhere Security Guide.
• Google Cloud: Workload Identity Federation uses workload identity pools and providers. A provider maps external token attributes to google.subject and custom attributes, and an attribute condition, written in CEL, decides which external credentials are accepted. Supported sources include AWS, Microsoft Entra ID, OIDC, SAML 2.0 and X.509 certificates. Google recommends granting roles directly to the federated principal where the target API supports it. On GKE, clusters use the pool PROJECT_ID.svc.id.goog. See the GKE Identity Hardening Guide and Google Cloud IAM and Service Accounts Guide.
• Microsoft Azure: managed identities (system-assigned, sharing the lifecycle of one resource, or user-assigned, a standalone resource that can be attached to several) obtain Microsoft Entra tokens without any credential the developer can see. Workload identity federation lets a managed identity or app registration trust an external token when its issuer, subject and audience match the federated identity credential case-sensitively. On AKS, Microsoft Entra Workload ID projects a Kubernetes service account token and exchanges it for an Entra token. See the Azure Managed Identities Security Guide and AKS Identity Hardening Guide.

Underneath, Kubernetes itself issues bound service account tokens through the TokenRequest API. These carry an audience and expiry and are rotated by the kubelet, and they are the token most cloud-native Kubernetes integrations exchange. See the Kubernetes Service Account Token Guide.

Side-by-side comparison

Trust domains and portability

The trust boundary is the deciding difference, so it is worth being precise about what each one means.

• A SPIFFE trust domain is the authority part of the SPIFFE ID. The specification notes that trust domain names are self-registered and have no delegating authority, so collisions are possible: choose names you control (for example a DNS name you own) and keep separate trust domains for separate security boundaries such as production and staging.
• Federation between trust domains is explicit. A relying party is configured with the other domain's bundle endpoint URL, profile and trust domain name. Nothing is trusted by default.
• A cloud trust boundary is the account, project or tenant. Federation into it is defined per provider: an AWS role trust policy, a Google workload identity pool provider with an attribute condition, or an Entra federated identity credential.
• Identity sameness: on GKE, clusters in the same project share one workload pool, so a namespace and service account with the same names in two clusters receive the same access. The Google documentation says you must therefore trust every cluster in the pool. SPIFFE IDs can encode the cluster in the path, but only if your registration scheme does so.
• Portability in practice: moving a workload between clouds changes its cloud-native principal and every policy that names it. Its SPIFFE ID can stay the same if the new environment is in the same trust domain, so service-to-service policies do not change.

When to use SPIFFE, cloud-native identity or both

Combining the two

The common pattern is to let SPIFFE be the workload's identity and to federate it into each cloud, so no cloud key is ever stored.

• OIDC route: the SPIRE OIDC Discovery Provider serves /.well-known/openid-configuration and a JWKS endpoint for JWT-SVID validation. A cloud provider that accepts OIDC federation can then accept JWT-SVIDs. Microsoft lists SPIFFE and SPIRE among the supported workload identity federation scenarios, and Google Cloud Workload Identity Federation accepts OIDC providers.
• X.509 route: IAM Roles Anywhere and Google Cloud Workload Identity Federation both accept X.509 certificates from a CA you register. SPIRE includes an aws_rolesanywhere_trustanchor bundle publisher plugin to keep the Roles Anywhere trust anchor in step with the SPIRE bundle.
• Bind narrowly: map the SPIFFE ID to a single subject in the cloud configuration (an exact sub in the Entra federated credential, a CEL attribute condition in Google Cloud, a trust policy condition in AWS). Never trust a whole trust domain for a privileged role.
• Keep JWT-SVIDs single-audience and short-lived: they are bearer tokens and can be replayed to any service named in aud.

For federation patterns between providers see Cross-cloud workload identity federation.

Implementation approach

1. Inventory static credentials first. List access keys, service account key files and client secrets used by workloads. These are the target of either approach. See the How to move GKE workloads from keys to Workload Identity Federation walkthrough for one example.
2. Move single-cloud workloads to cloud-native identity. This is the quickest risk reduction and needs no new infrastructure.
3. Decide whether you need cross-platform service identity. If services call each other across clusters, clouds or data centres, design a SPIFFE trust domain plan: names, environments, and the path scheme for IDs (for example /ns/<namespace>/sa/<service-account>).
4. Pilot SPIFFE on one service pair. Run SPIRE with registration entries using specific selectors, enable mTLS in permissive mode, and confirm SVID rotation before enforcing.
5. Federate into the clouds. Add the OIDC or X.509 route with one exact subject per role. Test in a non-production account.
6. Enforce and remove keys. Switch mTLS to strict, delete the old keys, and set organisation policies that block new key creation where the provider supports it.
7. Rollback plan: keep the previous credential disabled rather than deleted during the observation window, and keep permissive mTLS available per service so one failing workload can be reverted without affecting others.

Threat model, failure modes and a worked scenario for each option

SPIFFE

Threat model. The trust anchor is your own SPIRE server and its signing keys, so compromise of the server or a weak attestation policy lets an attacker mint valid identities for any workload in the trust domain. Failure modes. Registration entries keyed on easily spoofed selectors, broad JWT-SVID audiences, and federation bundles exchanged once and never refreshed. Controls. Harden and monitor the SPIRE server like a certificate authority, attest on strong node and workload selectors, prefer X509-SVIDs for service to service traffic and, where JWT-SVIDs are needed, follow the standard's advice to use single audiences and an aggressive expiry. Decision criteria. Choose SPIFFE when workloads span clouds, data centres or clusters and need one identity format.

Cloud-native workload identity

Threat model. The trust anchor is the cloud provider's metadata and token service. The attacker wants to reach that service from a compromised workload, or to exploit a trust policy that lets the wrong workload assume a role. Failure modes. Roles shared across many workloads, so one compromise reaches every resource, and identities that stop at the cloud boundary, which pushes teams back to static keys for anything outside it. Controls. One role per workload, conditions on namespace and service account, and federation rather than exported keys for cross-cloud calls. Decision criteria. Choose cloud-native identity when workloads live mainly in one provider.

Worked scenario. A company runs most services in one cloud and a batch platform on premises. Cloud workloads keep native identity. On premises, SPIRE issues SVIDs, and a federated trust lets those workloads exchange a JWT-SVID with a single audience for a short-lived cloud token, so no static cloud key is ever issued to the batch platform.

Detection and measurement

• Monitor: federated token exchanges in provider logs (role assumptions through Roles Anywhere or Pod Identity in CloudTrail, Security Token Service exchanges in Google Cloud Audit Logs, service principal sign-ins in Entra logs); SPIRE server registration entry changes; SVID issuance failures; bundle endpoint availability.
• Alert on: new federated credentials or pool providers; attribute conditions removed or widened; registration entries with broad selectors; any static key created for a workload that already has federation.

Common failure patterns

• Trusting the whole pool or trust domain: granting a role to every identity in a Google workload identity pool, or accepting any SPIFFE ID from a federated domain, turns one compromised workload into access for all.
• Ignoring identity sameness: assuming two GKE clusters in the same project are isolated when matching namespace and service account names receive the same access.
• Loose SPIRE selectors: registration entries that match on namespace only let any pod in that namespace obtain the identity.
• Multi-audience JWT-SVIDs: a token valid for several services can be replayed from one to another, as the JWT-SVID specification warns.
• Leaving the old key in place: federation is added but the service account key or access key is never deleted, so the static secret remains the weakest path. See Top 10 Workload Identity Mistakes.
• Unprotected issuer: treating the SPIRE server and its CA keys as ordinary infrastructure rather than tier-zero.

Framework mapping

For the zero trust context, see the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide.

Practitioner checklist

• List every static credential used by workloads and set a removal date for each.
• Use cloud-native identity for all single-cloud workloads calling their own provider's APIs.
• Adopt SPIFFE where services authenticate to each other across clusters, clouds or data centres.
• Name trust domains after DNS names you own and separate production from non-production.
• Bind each federated credential to one exact subject, never a whole pool or trust domain.
• Use specific SPIRE selectors (namespace plus service account at minimum) and review registration entries.
• Keep JWT-SVIDs single-audience and short-lived; prefer X.509-SVIDs and mTLS where possible.
• Protect the SPIRE server, its datastore and CA keys as tier-zero assets.
• Delete old keys after federation is proven, and block new key creation by policy.

Standards and references

• SPIFFE: The SPIFFE Identity and Verifiable Identity Document
• SPIFFE: JWT-SVID specification
• SPIFFE: Federation specification
• SPIRE: Server configuration reference
• AWS: EKS Pod Identity
• AWS: What is IAM Roles Anywhere
• Google Cloud: Workload Identity Federation
• Microsoft: Workload identity federation

Related NHI Mgmt Group resources: SPIFFE and SPIRE Guide · Cloud Workload Identity Guide · mTLS Guide · Service Mesh Security Guide · OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide