Static service passwords spread across CI pipelines are a massive breach vector.
Most teams grant a single database user to every automation job, then sprinkle that credential in config files, environment variables, and secret stores. The result is a "god" account that can read, write, and drop any table, and no one can tell which job performed a destructive query. Auditors see a single user in the logs, and developers cannot prove that a particular job respected the principle of least privilege.
Why non‑human identity alone is not enough
Adopting OIDC‑based service accounts or short‑lived tokens is a step forward. The identity provider now knows which CI job or microservice is making the request, and we write policies around group membership. However, the request still travels directly to Postgres, bypassing any enforcement point. The database sees a valid credential and executes the command without a second opinion. The system does not apply inline masking of sensitive columns, it does not provide a real‑time approval workflow to interrupt a risky ALTER, and it does not record sessions for later forensic analysis.
In this state, the setup, the identity system, decides who is allowed to start a connection, but it does not guarantee that the connection obeys least‑privilege constraints once it reaches the database. The risk remains that a compromised CI token could be used to exfiltrate customer PII or drop tables, and there is no immutable audit trail to prove otherwise.
Placing enforcement in the data path
The missing piece is a dedicated Layer 7 gateway that sits between the non‑human identity and the Postgres endpoint. By routing every connection through this gateway, the system gains a single choke point where policy can be evaluated, data can be masked, and activity can be recorded.
hoop.dev provides that data‑path enforcement. It proxies the PostgreSQL wire protocol, inspects each query, and applies the following enforcement outcomes:
- hoop.dev records each session, creating a replayable audit log that ties every statement back to the originating service account.
- hoop.dev masks sensitive fields, such as credit‑card numbers, in query results, ensuring that downstream logs never contain raw PII.
- hoop.dev blocks commands that exceed the declared least‑privilege scope, for example preventing a read‑only service from issuing DROP TABLE.
- hoop.dev routes high‑risk statements to a human approver before they are executed, adding a just‑in‑time approval step.
All of these controls happen because the gateway is the only place the traffic can be inspected. Without hoop.dev, the database would execute the statement unchecked.
How the pieces fit together
The workflow looks like this:
- Setup: An OIDC provider issues a short‑lived token to a CI job. The token carries the job’s service‑account identity and group claims.
- Connection request: The job presents the token to hoop.dev. The gateway validates the token, extracts the identity, and checks the request against the configured least‑privilege policy.
- Data‑path enforcement: hoop.dev forwards the request to Postgres only after applying masking rules, command blocks, or approval workflows. The database never sees the raw token or the original credentials.
- Enforcement outcomes: hoop.dev logs every query, hoop.dev returns masked results, and hoop.dev records any denied or approved actions for audit.
This architecture guarantees that least privilege is enforced not just at the identity layer but at the point where data actually moves.
Practical steps to adopt the model
Start by inventorying every automation job that talks to Postgres. Replace any hard‑coded passwords with OIDC‑backed service accounts. Next, deploy hoop.dev in a network segment that can reach your database. The official getting started guide walks through a Docker‑Compose deployment, an agent installation, and the basic policy schema. Once the gateway is running, define least‑privilege policies that map each service account to the specific schemas and tables it may access. The learn section contains detailed examples of masking rules and approval workflows.
After policies are in place, verify that the audit logs contain entries like “service‑account‑ci‑deploy SELECT FROM orders”, and confirm that hoop.dev rejects attempts to run prohibited statements with a clear error. Over time, you can tighten scopes further, confident that hoop.dev will block or record any deviation.
FAQ
Do I still need database‑level role management?
Yes. hoop.dev complements, rather than replaces, native Postgres roles. The gateway enforces policies at the wire level, while database roles provide a safety net for any direct connections that might bypass the gateway.
Will masking affect application logic?
Masking is applied only to result sets that flow back through the gateway. Applications that require the raw value must request it from a dedicated service with stricter access controls.
How does replay work for forensic analysis?
hoop.dev stores a chronological log of every command and its outcome. Security teams can replay a session to see exactly what a compromised token attempted, which helps root‑cause investigations.
By moving enforcement into the data path, you turn a vague “least privilege” aspiration into a concrete, enforceable control set. hoop.dev is the open‑source gateway that makes that possible.
Explore the source code and contribute on GitHub
