Notifications
Clear all
Topic starter
11/06/2026 11:24 pm
TL;DR: Workload attestation ties process-level evidence, container metadata, and node provenance into a verifiable identity signal before a workload receives credentials, according to Riptides. For practitioners, the critical shift is that workload identity becomes measurable only when evidence is collected from the kernel and surrounding runtime, not from mutable configuration.
NHIMG editorial — based on content published by Riptides: Kernel Workload Attestation and Metadata Gathering: Building Trust from the Ground Up
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 57% of organisations lack a complete inventory of their machine identities.
- 69% of organisations now have more machine identities than human ones.
Questions worth separating out
Q: How should security teams verify workload identity before issuing credentials?
A: Security teams should require verifiable process and runtime evidence before issuing workload credentials.
Q: Why do containers and Kubernetes metadata still need attestation?
A: Containers and Kubernetes metadata describe intent, but they do not prove the actual running process.
Q: What do teams get wrong about workload trust in cloud-native environments?
A: Teams often assume that scheduling a workload into a trusted cluster makes the workload itself trustworthy.
Practitioner guidance
- Collect kernel evidence before issuance Require attestation signals from /proc, cgroup, and runtime metadata before binding any short-lived workload credential.
- Prefer immutable artefacts over mutable labels Use image digests, pod UID, service account, and node provenance as the basis for policy.
- Separate collection from policy and issuance Keep evidence gathering read-only and distinct from the component that evaluates trust.
What's in the full article
Riptides' full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step collector design for process, container, orchestrator, node, and cloud evidence.
- Concrete examples of Linux interfaces such as /proc, cgroup data, and runtime APIs used for attestation.
- The flattened metadata schema that makes evidence deterministic across heterogeneous environments.
- Implementation guidance on how to keep attestation read-only, auditable, and portable.
👉 Read Riptides' analysis of kernel workload attestation and metadata gathering →
Workload attestation and kernel evidence: are your controls ready?
Explore further
12/06/2026 8:02 am
Workload attestation is the missing control layer between process truth and identity issuance. The article shows that a workload is not trustworthy because it is named, scheduled, or packaged. It becomes trustworthy only when kernel-level facts, image identity, and orchestrator intent align. That is the practical boundary between runtime observation and identity governance, and it belongs in every workload identity programme.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most NHI programmes still lack the inventory base needed for trustworthy attestation.
A question worth separating out:
Q: Who should own workload attestation in an identity programme?
A: Ownership should sit with the identity and platform teams together. IAM or NHI governance should define the trust policy, while platform engineering should operate the collectors and integration points. That split keeps attestation tied to identity governance rather than treated as a purely infrastructure feature.
👉 Read our full editorial: Workload attestation is the missing ground truth for workload identity
