Kubernetes audit logs need identity continuity to attribute engineers

At a glance

What this is: This is a practical analysis of why Kubernetes audit logs can fail to identify the individual engineer behind an action, especially when shared credentials, proxies, cloud IAM, and kubectl exec are involved.

Why it matters: IAM and platform teams need identity continuity across authentication and session paths so audit evidence remains attributable, investigable, and enforceable across human and machine-mediated access.

👉 Read Teleport's analysis of how to tie Kubernetes audit logs to individual engineers

Context

Kubernetes audit logging records the request that reached the API server, not always the person who typed the command. In mixed access paths, the username in the log can come from a shared certificate, a proxy identity, or a cloud sign-in layer, which makes individual attribution a governance problem rather than a logging problem.

For identity teams, the issue sits at the boundary between human IAM and platform access design. If the person record is not preserved through Kubernetes authn, impersonation, federation, and session handling, the audit trail may remain technically complete while still being operationally ambiguous.

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. Investigations can still show the namespace, Pod, and verb, but they cannot tell which person held the key or typed the command. That makes shared kubeconfigs a governance problem, not just an access convenience.

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. 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.

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. If the workflow includes kubectl exec, a proxy, or shared certificates, the audit log is insufficient on its own because it cannot reconstruct the interactive session or disambiguate the actor.

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.

Technical breakdown

How Kubernetes derives the username in an audit event

Kubernetes audit logs are written by the API server after authentication and authorization, so the username in the event reflects the identity material presented at request time. With client certificates, the common name and organization fields become the user and group claims. With bearer tokens or federated sign-in, the server records whatever identity the upstream authenticator asserts. That means the audit trail is only as precise as the identity source and the handoff into the cluster. If multiple people share one credential, or if an intermediary substitutes its own service identity, Kubernetes cannot reconstruct the original human actor from the event alone.

Practical implication: Preserve unique identities at the point of authentication, not just at the point of audit review.

Why kubectl exec breaks command-level attribution

An exec request creates a connection into a running Pod, but the API server does not inspect the terminal stream after the connection opens. The audit log can show who initiated pods/exec, the target object, and the response, yet it cannot see the shell commands, scripts, or interactive output that follow. That is a structural limitation of request auditing, not a product defect. If a recorder is not in the path, the terminal session exists as an opaque stream after the initial control-plane event. For investigations, that means the audit record proves connection initiation, while session reconstruction requires a separate telemetry layer.

Practical implication: Use session recording when the investigation needs terminal content, not just connection metadata.

How proxies and cloud IAM can preserve or replace the person record

A proxy can either preserve user identity through impersonation or erase it by authenticating only as itself. The same pattern appears in cloud IAM and managed Kubernetes: the upstream system may know the engineer, but the cluster only records the identity that finally reaches the API server or audit backend. Good designs carry a stable person record through every hop while keeping the proxy or federation layer as a conduit, not a replacement. Poor designs collapse distinct engineers into one service identity, which makes accountability depend on external logs and tribal knowledge instead of the cluster record itself.

Practical implication: Require identity propagation rules that keep the engineer visible across proxies, federation, and managed-cluster logging.

Threat narrative

Attacker objective: The objective is to perform or obscure privileged cluster actions while preventing investigators from tying those actions to a specific engineer.

1. Entry occurs when an engineer connects through a shared kubeconfig, proxy, or cloud sign-in path that presents a reusable identity to Kubernetes.
2. Credential access is effectively hidden when the same certificate, token, or proxy identity can be used by multiple people, collapsing attribution into one username.
3. Impact follows when the audit record cannot distinguish who opened the shell or which commands were typed after pods/exec started.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Shared credentials create attribution collapse, not just access risk. When two engineers use the same kubeconfig or client certificate, the cluster cannot separate their actions because it sees the same authenticated subject twice. This is not merely poor hygiene, it breaks the investigative value of the log. Teams should read that as a governance failure in identity assignment and issuance, not just a credential management issue.

Session recording is a distinct control plane from audit logging. kubectl exec establishes a terminal stream that the API server cannot inspect after the connection opens, so request logs and shell replay solve different problems. The named concept here is audit-to-session gap: the evidence chain stops at connection initiation unless a recorder preserves the interactive stream. Practitioners should design for both control-plane attribution and session-level reconstruction.

Proxies must pass the person through, not stand in for the person. A proxy that authenticates only itself makes the cluster record the proxy, while impersonation or delegated identity can preserve the original engineer. The decisive question is whether the intermediary enriches audit evidence or substitutes its own identity for it. The practitioner implication is to validate identity propagation at every intermediary, especially in centralised access architectures.

Managed Kubernetes logging choices determine whether identity is recoverable. Cloud platforms may split useful evidence across audit, data access, and diagnostic settings, which means the person record can disappear even when the action succeeded. That is a governance design choice, not a logging accident. Teams operating cloud-managed clusters should verify where the identity field lives before they rely on the log for investigations.

From our research library:

• 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.

What this signals

Audit-to-session gap: Kubernetes request auditing and terminal replay solve different governance problems. If your programme treats them as interchangeable, you will either miss shell activity or overestimate what the audit trail can prove. The correct design question is whether the person remains identifiable after the connection opens.

Managed clusters make identity continuity a cross-layer requirement, not a single control choice. Once authentication, proxying, and logging live in different systems, the person record can fragment unless teams test it end to end. That affects incident response, access reviews, and accountability for human operators, service identities, and delegated access paths alike.

For practitioners

• 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.
• Record interactive sessions separately Add session recording for kubectl exec paths where terminal contents matter, because audit logs stop at the connection boundary.
• Validate cloud audit log retention for identity fields Confirm that managed Kubernetes audit settings keep the caller identity, request target, and response details in the destination you actually review.

Key takeaways

• 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.
• The article shows that the audit trail may preserve username, target, and response while still losing the ability to prove who actually held the credential or typed in the shell.
• The practical fix is to keep per-engineer identity intact through proxies and cloud IAM, and to add session recording wherever exec activity must be replayable.

Key terms

• Identity Continuity: Identity continuity is the ability to preserve a workload’s verified identity across proxies, services, and other infrastructure boundaries. It matters because zero trust breaks down when a request loses its original proof of identity and falls back to network trust or header-based assumptions.
• Kubectl Exec: Kubectl exec is the command used to run an interactive process inside a container that is already running in a Kubernetes pod. It is commonly used for troubleshooting and inspection, but it should be treated as privileged access because it lets users operate directly inside the workload runtime.
• Audit Attribution: The ability to prove who requested an action, which actor executed it, and what resource was affected. In AI agent governance, attribution must be richer than a single username because accountability breaks when the human and the agent share one visible identity.
• Session Recording: Session recording is the capture of user activity during a privileged session, such as commands, queries, or administrative actions. It gives security and audit teams a verifiable record of what happened after authentication, which is essential when access itself is not enough to prove control.

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

👉 Teleport's full post shows the audit fields, proxy identity paths, and exec-session recording details in practice.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.