A freshly provisioned CI pipeline runs under a service account that can create, delete, and patch any pod in the cluster. The same credential is also used by an automated backup job, a nightly security scan, and a third‑party monitoring agent. When the backup job is misconfigured it tries to write to a namespace it should never touch, and the scan tool accidentally deletes a deployment because the token it carries has cluster‑admin scope.
This scenario shows why non‑human identities can explode your blast radius. A single token, once compromised or misused, can reach far beyond the intended workload. The problem is not the lack of an identity – the service account does give you a name to attach to the request – but the fact that the request flows straight to the Kubernetes API server without any guardrails that can see what is being done.
What non‑human identity alone does not solve
Switching from a shared password to a dedicated service account is a necessary step. It lets you audit which automation performed an action, and it enables you to grant the minimum set of RBAC permissions for that workload. However, the token still travels directly to the API server. The gateway that sits between the automation and the cluster is missing, so there is no place to enforce real‑time policies.
Because the request bypasses any proxy, you lose three critical controls:
- Visibility into the exact command or API call before it is executed.
- Ability to mask sensitive fields in responses, such as secrets returned by kubectl get secret.
- Just‑in‑time approval for risky operations, like deleting a namespace or scaling a stateful set beyond a safe threshold.
In short, the setup gives you a named identity and a tighter RBAC policy, but it leaves the blast radius unchecked. If the service account is stolen, the attacker can still issue any API call the role permits, and you have no audit trail that captures the intent before the action happens.
Why the data path must host enforcement
To shrink the blast radius you need a control point that sits on the traffic between the automation and the Kubernetes API. That control point must be able to inspect the wire‑protocol, apply policies, and record what happened. It cannot be placed inside the pod or the CI runner, because a compromised process could simply bypass the checks.
When the gateway sits in the data path, it becomes the only place where every request can be examined. This is where enforcement outcomes are realized:
- hoop.dev records every Kubernetes command so you have a replayable audit trail for forensic analysis.
- hoop.dev masks secret data in API responses before it reaches the automation, preventing accidental leakage.
- hoop.dev blocks dangerous commands such as kubectl delete namespace unless an explicit approval is provided.
- hoop.dev routes high‑risk operations to a human approver in real time, turning a potentially catastrophic change into a controlled workflow.
All of these capabilities depend on the gateway being the sole point of entry for the connection. The identity system (OIDC, SAML, service account tokens) decides who is making the request, but without the gateway in the data path you cannot guarantee that the request is safe.