Cloud-native federation for NHIs: where the governance gap still sits

TL;DR: Cloud-native federation across AWS, GCP, and Azure reduces secret handling, but it still leaves shared instance identity, token lifecycle, and workload isolation gaps that can expose entire hosts, according to Riptides. The governance problem is no longer whether federation works, but whether the identity model can prove per-workload accountability at runtime.

NHIMG editorial — based on content published by Riptides: Why Cloud-Native Federation Isn’t Enough for Non-Human Identities in AWS, GCP, and Azure

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should security teams govern cloud-native federation for non-human identities?

A: Security teams should govern cloud-native federation at the workload level, not just the instance level.

Q: Why do shared identities in cloud-native environments increase NHI risk?

A: Shared identities increase risk because one compromise can inherit the same permissions as every other workload on the host.

Q: When is cloud federation not enough for workload identity governance?

A: Cloud federation is not enough when you need to distinguish one workload from another on the same host, container node, or VM.

Practitioner guidance

• Map every cloud credential to its actual runtime subject Document whether each AWS, GCP, or Azure identity is bound to a host, a VM, a container, or a specific workload execution context.
• Test whether metadata-service access is process-scoped or host-scoped Validate which local processes can reach instance metadata, token endpoints, or credential files on each platform.
• Treat token retrieval and delivery as part of the control surface Review how short-lived credentials are fetched, cached, handed off, and revoked in memory and on disk.

What's in the full article

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

• Kernel-level enforcement flow for matching workload attributes to SPIFFE-based identity.
• sysfs-based credential delivery and why it matters for runtime scoping.
• On-the-wire credential replacement details for cloud SDK traffic.
• Kubernetes custom resource examples for CredentialSource, WorkloadCredential, and WorkloadIdentity.

👉 Read Riptides' analysis of cloud-native federation limits for NHI governance →

Cloud-native federation for NHIs: where the governance gap still sits?

Explore further

View Full Forum →  |  NHI Foundation Course →