Most CI/CD pipelines start with a single service account that every job shares, and the account is granted wide‑ranging permissions to databases, storage, and clusters, violating the principle of least privilege. The secret for that account lives in configuration files, environment variables, or even the repository itself, so it travels with the code, appears in logs, and can be extracted from container images. When a compromise occurs, the attacker inherits every permission the shared account holds, turning a single build failure into a full‑blown breach.
Teams often try to tighten the situation by creating a few more service accounts, but they still rely on static credentials that are handed to the pipeline at start‑up. The identity provider authenticates the job, yet there is no point in the network where the request can be inspected, masked, or recorded. The pipeline reaches the target directly, so any over‑reach happens unchecked and no reliable audit trail exists.
What is missing is a data‑path enforcement layer that sits between the non‑human identity and the infrastructure. The setup – OIDC tokens, purpose‑built service accounts, and least‑privilege role definitions – decides who may start a request, but it cannot enforce that the request stays within its bounds. Without a gateway, you cannot apply command‑level audit, inline masking of secrets, just‑in‑time approval for risky operations, or immutable session recordings.
hoop.dev as the identity‑aware gateway
hoop.dev fills that gap by acting as the only point where traffic between a CI job and its target passes. It validates the OIDC or SAML token issued by the identity provider, reads the groups or roles attached to the service account, and then enforces policy at the protocol level. Because hoop.dev occupies the data path, it can:
- Record each pipeline session, producing a replayable audit log that ties every command to the specific non‑human identity.
- Mask sensitive fields, such as database passwords or API keys, in responses before they reach the CI job.
- Require just‑in‑time approval for high‑risk operations, routing the request to a human reviewer while the rest of the pipeline continues.
- Block disallowed commands outright, preventing accidental or malicious misuse of credentials.
All of these outcomes exist only because hoop.dev sits in the gateway position. The setup – OIDC federation, service‑account creation, and least‑privilege role definition – remains necessary to decide who may start a request, but the enforcement lives in hoop.dev.
How the pieces fit together
1. Define a purpose‑built service account for each pipeline stage. Use your identity provider to issue short‑lived OIDC tokens that carry only the permissions needed for that stage. This is the setup that determines who the request is.
2. Deploy hoop.dev inside the network where the target resource resides. The gateway holds the static credential for the downstream system, so the pipeline never sees it. This creates the data path where enforcement can happen.