An offboarded contractor’s CI job continues to run under a service account that can impersonate any pod in the cluster. The result is a classic data exfiltration path. The job pulls a database dump, writes it to a temporary volume, and then uses a side‑car container to upload the archive to a personal cloud bucket. No one notices because the job’s identity appears legitimate, and the network traffic looks like ordinary internal traffic.
That scenario illustrates a broader class of risk: Kubernetes agents – typically service accounts, CI runners, or custom controllers – can be instructed to act as another identity. The Kubernetes API includes an Impersonate-User header that lets a holder of a token request actions on behalf of any user or service account, provided the original token has the impersonate permission. When that permission is granted too broadly, an attacker who compromises a low‑privilege component can gain a privileged identity and reach data that should be out of scope.
Data exfiltration via impersonation follows a predictable path. First, the compromised agent reads secrets from the kube‑system namespace or from custom Secret objects that store database credentials, API keys, or TLS certificates. Second, it uses those credentials to connect to downstream services – databases, object stores, or internal APIs – and extracts data. Finally, it leverages any outbound network capability – a pod with hostNetwork, a side‑car that runs curl, or a misconfigured NetworkPolicy – to ship the data outside the trusted perimeter.
Why agent impersonation fuels data exfiltration
Impersonation removes the need for the attacker to obtain a privileged token directly. Instead, the attacker only needs a token that can call the impersonate sub‑resource. Because Kubernetes RBAC is often granted at a namespace level, a single service account may inadvertently inherit impersonate rights for the whole cluster. The attacker can then request the API server to act as the system:admin user, list all secrets, and extract them without ever touching the original privileged credentials.
Once the secrets are in hand, the attacker’s pod can launch a second phase: creating a temporary job or a CronJob that runs a data‑dump command, then opening an outbound TCP connection to a remote endpoint. Because the outbound traffic originates from a pod that already has a legitimate IP address, traditional network monitoring may miss the exfiltration attempt.
Signals to watch for
- Audit log entries that contain the Impersonate-User header, especially when the impersonated identity is a cluster‑admin or a service account with secret‑access.
- Service accounts that suddenly acquire new impersonate permissions in a short time window – a sign of privilege‑escalation.
- Pods that mount service‑account tokens and also have elevated NetworkPolicy rules allowing egress to the internet.
- Unexpected creation of Job or CronJob resources that run data‑dump utilities.
- High‑volume reads from Secret objects followed by outbound connections from the same pod.
Detecting these patterns requires correlating Kubernetes audit logs, network flow data, and workload manifests. However, detection alone does not stop the exfiltration – you need an enforcement point that can intervene before the malicious command reaches the API server.
Enforcing controls with a data‑path gateway
Identity configuration (OIDC, RBAC, service‑account tokens) decides who can ask for access, but it cannot stop a legitimate request from being misused. The only place to enforce policies such as “block impersonation unless explicitly approved” or “mask secret values in API responses” is the data path that sits between the client and the Kubernetes API server.