Failure Pattern
Kubernetes assumes control-plane components, nodes, and pods operate honestly. Attackers exploit these assumptions.
What We See in the Field
A compromised pod uses inherited service accounts to call internal APIs. RBAC passes. Network policies allow traffic. Kubernetes trusts a malicious actor because identity is inherited.
Underlying Causes
Service accounts reused
Certificates shared across pods
Node trust assumptions
Lack of tamperproof workload identity
Orchestrator metadata used for identity
Trust-Native Network Resolution
DTL assigns immutable TrustKeys to each workload. Pods cannot inherit identity or impersonate others.
Broken Trust Assumption
The attacks that exposed this failure pattern were not stealthy break-ins. They were trusted operations.
During incidents such as SolarWinds, Capital One, and Okta, malicious activity was carried out using valid identities and approved execution paths. Certificates were valid. Tokens were accepted. Sessions were authenticated. From the system’s point of view, nothing appeared wrong.
This is the risk of trust inferred from credentials, location, or prior authentication.