A single over‑privileged service account can explode your blast radius across GCP. When that credential is copied, cached, or left unattended, an attacker who compromises it can move laterally, read data, and spin up resources without any visibility.
Most teams treat non‑human identities as a convenience: they create a service account, grant it Owner or a broad set of roles, and embed the key in CI pipelines, Terraform modules, or custom scripts. The key lives in source control, in container images, or on developer laptops. When a developer leaves, the key often remains, and when a CI runner is compromised, the attacker inherits the same sweeping permissions. The result is a massive, uncontrolled blast radius that can affect every project, every bucket, and every compute instance in the organization.
Why non‑human identities inflate the blast radius
Non‑human identities, service accounts, workload identities, and automation tokens, are usually granted once and never revisited. Because they are not tied to a person, there is no natural trigger to rotate them or to audit their usage. The following patterns are common:
- Static JSON keys stored in Git repositories.
- Service accounts with Owner or Editor roles covering multiple projects.
- Long‑lived tokens used by bots that run in many environments.
Each pattern gives the holder the ability to perform actions far beyond the original intent. If the token is exfiltrated, the attacker can create new service accounts, modify IAM policies, or delete data, all while the original team remains unaware.
What a proper control model must include
Reducing blast radius starts with a solid setup: identity providers such as Google Cloud IAM issue short‑lived tokens, roles are scoped to the minimum set of permissions, and service accounts are tied to specific workloads. This setup decides *who* a request is and whether it may start, but it does not enforce anything once the request leaves the identity check.
Without an enforcement point in the data path, the request reaches the target resource directly. The connection proceeds without a record of what command was run, without any chance to mask sensitive fields in a response, and without an opportunity for a human to approve a risky operation. In other words, the blast radius remains uncontrolled.
Putting enforcement in the data path
The missing piece is a Layer 7 gateway that sits between the identity system and the GCP services. By proxying every API call, database query, or SSH session, the gateway becomes the sole place where policy can be applied. It can:
- Record each session for replay and audit.
- Mask sensitive fields (for example, API keys returned in a response) before they reach the caller.
- Require just‑in‑time approval for high‑risk actions such as creating a new service account or deleting a bucket.
- Block commands that match a deny list, preventing accidental or malicious misuse.
These enforcement outcomes exist only because the gateway sits in the data path. If the gateway were removed, the same request would flow straight to GCP and none of the controls would be applied.
How hoop.dev provides the needed controls
hoop.dev is an open‑source, identity‑aware proxy that implements exactly this architecture. It authenticates users and bots via OIDC, reads group membership, and then proxies the connection to the target GCP service. Because the gateway is the only point that sees the traffic, hoop.dev can enforce masking, approval, and session recording on every request.
With hoop.dev in place, a service account used by a CI pipeline no longer has unrestricted, invisible access. Each API call is logged, any response containing secrets is redacted, and attempts to perform privileged actions trigger an approval workflow that can be satisfied by a human or an automated policy engine. The blast radius is therefore bounded by the policies defined in the gateway, not by the original token’s permissions alone.
Getting started is straightforward: deploy the gateway using the getting started guide, register your GCP resources, and configure the desired guardrails. For deeper guidance on policy design, see the hoop.dev learn site. The documentation walks through connecting a service account, defining just‑in‑time approvals, and enabling session replay.
Practical steps to shrink your blast radius
- Scope service account roles. Grant only the permissions required for the specific workload.
- Rotate keys regularly. Use short‑lived OIDC tokens wherever possible.
- Introduce a gateway. Deploy hoop.dev as the sole path to GCP APIs and services.
- Define approval policies. Require manual or automated approval for actions that create or modify IAM bindings.
- Enable session recording. Store audit logs outside the workload so that compromised agents cannot tamper with evidence.
These steps turn a flat, unrestricted token into a controlled, observable interaction that limits how far an attacker can move.
FAQ
Does hoop.dev replace IAM?
No. IAM still decides who can obtain a token. hoop.dev sits after that decision point and enforces policies on the actual traffic.
Can I use hoop.dev with existing CI pipelines?
Yes. By routing the pipeline’s service‑account calls through the gateway, you gain audit and approval without changing the pipeline logic.
What happens if the gateway itself is compromised?
The gateway stores credentials but never exposes them to the caller. Compromise would be detected through its own session logs, and because the gateway is a single, observable point, you can quickly isolate and rotate any affected service accounts.
Explore the open‑source code on GitHub to see how the gateway is built and to contribute your own extensions.
