Agent impersonation: what it means for your blast radius (on Kubernetes)

An offboarded contractor’s service account still appears in the cluster’s RBAC list, and a CI job that runs with a broad token can spin up pods across every namespace. The result is a single credential that can be used to act as any identity inside the cluster, dramatically widening the blast radius of a breach.

Why agent impersonation inflates blast radius

In many Kubernetes deployments, teams rely on a handful of long‑living kubeconfig files or service‑account tokens that are shared across scripts, automation pipelines, and human operators. Those tokens often carry permissions far beyond the specific task they were created for. When an attacker obtains such a token, they can issue an impersonate request and assume the identity of any service account, including those with cluster‑admin rights. Because the API server trusts the presented token, the attacker can create, modify, or delete resources in any namespace, exfiltrate secrets, and disrupt workloads.

The core problem is not the lack of RBAC rules – most clusters have them – but the fact that the enforcement point lives inside the API server itself. The server validates the token, then immediately honors the impersonation request without any external check. There is no audit trail that links the impersonation to a specific engineer, no just‑in‑time approval step, and no way to block a dangerous command before it reaches the control plane.

Where the control gap lies

The current workflow can be broken down into three layers:

• Setup: Identity providers issue OIDC or SAML tokens, CI pipelines store service‑account keys, and administrators grant roles. This layer decides who may start a request, but it does not enforce what the request can do.
• The data path: The request travels directly from the client to the Kubernetes API server. No intermediary inspects the payload, so any impersonation request passes unchecked.
• Enforcement outcomes: Because the data path lacks a gate, there is no session recording, no inline masking of secret fields, and no approval workflow. If the request succeeds, the cluster records only the API server’s own logs, which are difficult to correlate with the originating engineer.

Because the enforcement point is missing, the blast radius of a compromised token remains unrestricted. Even if the setup layer is hardened – for example, by rotating tokens regularly – the moment a token is stolen the attacker can still impersonate any identity and cause widespread damage.

hoop.dev as the enforcement point

hoop.dev inserts a Layer 7 gateway between the client and the Kubernetes API server. All kubectl, client‑go, or script traffic is forced through this gateway, making the gateway the sole data path for every API call. Because hoop.dev sits in front of the API server, it can enforce policies that the server itself cannot.

When a request attempts to use the impersonate subresource, hoop.dev evaluates the request against a policy that may require just‑in‑time approval, block the operation entirely, or limit it to a predefined set of target service accounts. The gateway records the full request and response, masks secret fields in the response, and stores a replayable session for later audit. Because the gateway holds the credential used to talk to the API server, the downstream agent never sees the underlying token.

Key enforcement outcomes

• hoop.dev blocks impersonation attempts that lack an explicit approval, preventing a compromised token from widening blast radius.
• hoop.dev records every API call, including the identity that originated it, creating a reliable audit trail.
• hoop.dev masks sensitive fields such as data in Secrets, so even a privileged operator cannot view raw secret values without proper justification.
• hoop.dev enables just‑in‑time access, granting elevated permissions only for the duration of a specific operation.
• hoop.dev captures a replayable session, allowing post‑mortem analysis of what commands were issued and what resources were affected.

All of these outcomes exist because hoop.dev sits in the data path; removing the gateway would instantly eliminate the protections.

Getting started with a secure Kubernetes gateway

To retrofit these controls, deploy the hoop.dev gateway in the same network segment as your Kubernetes API server. The official getting‑started guide walks you through a Docker‑Compose deployment, OIDC configuration, and the registration of a Kubernetes connection. The learn section provides deeper coverage of policy definition, session replay, and inline masking.

FAQ

Q: Does hoop.dev replace Kubernetes RBAC?
A: No. hoop.dev augments RBAC by adding a gate that can enforce additional checks, record activity, and mask data before the API server processes the request.

Q: Will existing CI pipelines need to be rewritten?
A: Only the endpoint changes. Pipelines continue to use the same client libraries; they point to the gateway instead of the raw API server.

Q: Is the gateway itself a single point of failure?
A: hoop.dev can be deployed in a highly available configuration, and because it does not store long‑term secrets, failure does not expose credentials.

Ready to tighten the blast radius of your Kubernetes environment? Explore the source code and contribute at https://github.com/hoophq/hoop.