Because the cluster can only log the identity that reaches the API server after authentication and delegation. If a proxy authenticates as itself, or a cloud control plane writes a different principal than the person who signed in upstream, the audit trail reflects the intermediary instead of the operator. Identity propagation has to be explicit to avoid that loss.
Why the log line often shows the intermediary instead of the engineer
Kubernetes audit and API logs record the identity that actually presents to the API server, not the upstream human who may have initiated the action. If a proxy, cloud iam hop, or automation layer authenticates on behalf of someone else, the cluster sees the caller of record, while the real operator becomes an upstream context that can be lost unless identity propagation is designed into the path.
This is most visible when delegation is implicit. A reverse proxy, ingress controller, cloud control plane, or platform service can terminate one identity and reissue another, so the audit record faithfully captures the security boundary that Kubernetes can observe, but not necessarily the original person behind the request.
That distinction matters because logs are evidence of an access decision, not a full narrative of intent. If you want the engineer named in the audit trail, the architecture has to preserve that attribution through headers, impersonation controls, federation claims, or correlated upstream logs, rather than assuming the Kubernetes control plane will infer it later.
Where attribution breaks in real Kubernetes access paths
Attribution usually breaks at the handoff points between systems. Cloud IAM may authenticate a user, but a workload, proxy, or managed service may then assume a role, exchange a token, or call the API server using its own principal. The Kubernetes log is then accurate for the last authenticated hop, but incomplete for human attribution unless the chain is intentionally preserved.
Service accounts, workload identities, and cloud-native proxies are especially prone to this pattern because they are designed to remove static credentials from the path. That is good for security, but it also means the observable identity can shift from the operator to the intermediary unless the platform records the original subject separately and consistently.
Architecturally, this is an identity propagation problem, not just a logging problem. The difference between “who signed in upstream” and “who reached the API server” is the difference between business accountability and protocol truth, and both matter when you are reconstructing administrative activity or investigating an incident.
How to keep audit trails useful without breaking delegation
The fix is to make delegation explicit and inspectable. When a proxy or cloud control plane is allowed to act, it should do so with a clear delegated identity model, so the platform can distinguish the authenticating principal, the acting principal, and any impersonated or assumed role in the path.
For Kubernetes environments, that usually means aligning API access with the surrounding identity chain rather than depending on a single log source. Correlate cluster audit logs with cloud control plane logs, IdP events, and proxy access logs so you can reconstruct the full sequence instead of treating one record as complete evidence.
It also means being strict about what the intermediary is allowed to do. If a proxy authenticates as itself, its credentials should be limited to the minimum it needs, and any impersonation or token exchange should be tightly scoped. Cloud Workload Identity Guide is a useful reference when you need to separate human sign-in from workload presentation in cloud and Kubernetes paths.
Risk and Threat Considerations
When attribution is lost, accountability weakens and investigation quality drops. The security risk is not only “bad logs”, it is that an abused proxy, overprivileged cloud principal, or shared control-plane identity can mask who actually exercised administrative power, making detection, containment, and post-incident review slower and less reliable.
Failure mechanism: The upstream actor authenticates successfully, but a later hop reauthenticates, assumes, or proxies the request under a different principal, so the audit trail records the intermediary rather than the original engineer.
Impact: Security teams may misattribute privileged actions, miss the true source of misuse, and lose the evidence needed to prove whether a human, service, or automation path performed the action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Kubernetes audit records depend on what the API server can observe. |
| IA-9 — Service Identification and Authentication | Proxies and control-plane hops often authenticate as services or workloads. | |
| AC-6 — Least Privilege | Intermediaries should only hold the authority needed to proxy or delegate. | |
| Recommendation — Define audit events so delegated identity hops are captured and correlated. Authenticate service hops distinctly from end users and preserve delegation context. Limit intermediary authority so delegated access cannot obscure broad misuse. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Explicitly validates identities and trust boundaries across hops and proxies. |
| Recommendation — Treat each hop as a separate trust decision and preserve identity context end to end. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud IAM mediation is central to how identities are translated before Kubernetes sees them. |
| Recommendation — Map cloud-to-cluster identity translation and retain the upstream principal in logs. | ||
Practitioner Guidance
What to verify: Confirm whether your cluster logs the original subject, the delegated subject, or only the final caller. If the answer is “final caller only,” treat the audit trail as incomplete until you have correlated it with upstream identity and proxy records.
Decision rule: If a platform component can act on behalf of users, require an explicit delegation model, constrained permissions, and a separate source of truth for the upstream signer. If it cannot preserve that chain, do not rely on Kubernetes logs alone for attribution or for admin activity review.
Practitioner takeaway: The goal is not to make every log line name the human directly, it is to ensure the chain of custody for identity survives every proxy, token exchange, and cloud IAM handoff.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org