When a service account can scan every table in a data warehouse, the cost is more than a bloated bill, it’s a direct pathway for data leakage, accidental deletions, and compliance violations. Without enforcing least privilege, a single over‑privileged service account can compromise the entire warehouse. Over‑privileged non‑human identities turn a harmless analytics job into a high‑risk vector.
In many organizations, the default pattern is to create a single BigQuery service account, grant it the bigquery admin role, and embed its key in CI pipelines. The account never expires, the key is copied into multiple repositories, and there is no record of who ran which query. The result is a blind spot: anyone who can trigger the pipeline inherits the same broad access, and the audit trail is limited to the pipeline logs, not the actual data operations.
Why the current setup falls short of least privilege
The identity provisioning step – creating a service account, assigning a role, and distributing a credential – decides who can start a request. It is necessary, but it does not enforce any constraints on the request itself. The request still travels directly to BigQuery, bypassing any gate that could verify the operation, mask sensitive columns, or require an extra approval step.
Because the gateway is missing, the following gaps remain:
- Unrestricted queries run with full admin rights.
- No real‑time approval for expensive or destructive operations.
- No masking of personally identifiable information (PII) in query results.
- Session data lives only in the pipeline’s logs, which are easy to overwrite or delete.
How hoop.dev provides the missing enforcement layer
hoop.dev is a Layer 7 gateway that sits between non‑human identities and BigQuery. It becomes the only place where enforcement can happen. When a request arrives, hoop.dev validates the OIDC token, checks group membership, and then proxies the connection to BigQuery using a credential that only the gateway ever sees.
Because the gateway is in the data path, hoop.dev can apply the following least privilege controls:
- Just‑in‑time access: a service account receives a short‑lived token only for the specific query it needs to run.
- Inline masking: columns that contain PII are redacted before they reach the caller.
- Command‑level approval: expensive DML statements trigger a human workflow before execution.
- Session recording: every query and its result set are stored for replay and audit, independent of the pipeline.
All of these outcomes exist because hoop.dev sits in the data path; the underlying identity and IAM configuration alone cannot provide them.
What to watch for when you adopt non‑human identities
Even with a gateway, the security posture depends on how you configure the surrounding pieces. Keep an eye on these areas:
- Scope service accounts tightly. Use BigQuery’s fine‑grained roles, such as data viewer on a specific dataset, instead of broad admin rights.
- Rotate credentials regularly. Let hoop.dev generate short‑lived tokens; avoid long‑term static keys in CI.
- Enforce least‑privilege policies in the gateway. Define policies that limit which tables a given non‑human identity can query and which SQL commands are allowed.
- Enable masking for sensitive columns. Identify PII fields in your schema and configure hoop.dev to redact them on the fly.
- Audit every session. Verify that logs are retained outside the pipeline’s environment so they cannot be tampered with.
By aligning the identity provisioning step with an effective data‑path gateway, you move from “who can start” to “what they can actually do”. That shift is the essence of true least privilege for non‑human identities.
Getting started
To try this approach, follow the getting started guide and review the feature overview for policy configuration details. The repository contains the Docker Compose quick‑start that deploys the gateway alongside a sample BigQuery connection.
FAQ
Q: Do I need to change my existing service accounts?
A: You can keep the accounts, but you should restrict their IAM roles and let hoop.dev issue short‑lived tokens for each operation.
Q: Does hoop.dev store my BigQuery credentials?
A: The gateway holds the credential only in memory while proxying a request. The original service account never sees the key.
Q: Can I see who ran a specific query?
A: Yes. hoop.dev records each session with the identity that initiated it, the exact SQL statement, and the result set (subject to masking).
Explore the open‑source repository on GitHub to dive deeper into the implementation and contribute your own extensions.
