Topic starter
11/10/2026 6:56 pm
TL;DR: Teleport explains that Kubernetes audit logs can name a user, namespace and Pod, but shared kubeconfigs, proxy-mediated sign-in and cloud IAM can replace the individual engineer unless identity is preserved end to end. The real control problem is not logging volume, but keeping the person record intact through authentication, delegation and exec sessions.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “How to Tie Kubernetes Audit Logs to Individual Engineers”.
Key questions
Q: What breaks when engineers share a Kubernetes credential?
A: Shared credentials collapse audit attribution because Kubernetes records the same authenticated subject for every request made with that credential.
Q: Why do proxies and cloud IAM sometimes hide the real engineer in Kubernetes logs?
A: Because the cluster can only log the identity that reaches the API server after authentication and delegation.
Q: How do you know if Kubernetes audit logging is actually enough for investigations?
A: Audit logging is enough only when the event can identify a unique engineer and the action of interest happens entirely at the request level.
Practitioner guidance
- Enforce per-engineer Kubernetes identities Issue separate client certificates, tokens, or federated identities to each engineer so one audit username maps to one person and not a shared team credential.
- Preserve identity through proxy hops Configure proxies and federation layers to forward the engineer's identity with impersonation or delegated claims instead of authenticating only as the proxy.
- Disable shared kubeconfigs in production Remove reusable kubeconfig files from shared locations and rotate any credential that has been distributed to more than one operator.
Bottom line: Kubernetes audit logs can record a request cleanly and still fail to identify the individual engineer behind it when credentials are shared or replaced upstream.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how Kubernetes audit fields change across direct access, shared kubeconfigs, and proxy-mediated requests
- Cloud-specific logging paths for GKE and AKS, including where the person record appears in each platform
- Concrete kubectl exec examples showing why the API server stops at connection initiation
- Session recording behaviour for terminal traffic and how replay differs from standard audit logs
👉 Read Teleport's analysis of how to tie Kubernetes audit logs to individual engineers →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
Identity continuity is the real control, not audit volume. Kubernetes can record requests faithfully and still fail governance if the person behind the request changes at a proxy, federation layer, or shared credential. The audit event is only reliable when the same human identity survives every hop into the cluster. The practitioner conclusion is simple: treat identity propagation as part of the control design, not as a reporting afterthought.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: Should teams rely on audit logs or session recording for exec access?
A: Use both when production shell access is allowed. Audit logs prove who opened the connection and where, while session recording preserves what happened inside the shell. If you only need to know that an exec session occurred, audit may be enough. If you need replayable evidence, the recorder is the control that closes the gap.
👉 Read our full editorial: Kubernetes audit logs need identity continuity to attribute engineers