Many assume that simply creating a service‑account key automatically satisfies SOC 2 because the key is “a credential”. The reality is that a credential alone does not provide the audit trail, least‑privilege enforcement, or approval workflow that SOC 2 expects.
In most organizations, engineers copy a JSON key file into a shared repository, grant the associated service account broad roles such as Editor or Owner, and then invoke cloud tools directly from CI pipelines. The key lives on disks, in container images, and sometimes in environment variables. No central component observes each API call, no request receives a review for intent, and no response data ever gets masked. When a breach occurs, the forensic record shows only that a key was used, not which pipeline triggered the call or what data was returned.
SOC 2’s Access Control and Audit Logging criteria demand evidence that every access request ties to an identity, that the request receives authorization, and that the action records in an immutable log. The current practice of static keys fails those requirements because the enforcement point resides in the service itself, not in a controlled gateway.
Teams need a way to govern non‑human identities, service accounts, workload identities, and CI agents, while still allowing those identities to reach GCP services directly. The precondition is that the identity token verifies, the request scopes to the minimum set of permissions, and the request flows to the target. However, without a dedicated enforcement layer, the request arrives at Cloud SQL, GKE, or Cloud Storage unchanged: GCP emits its own logs, but no inline masking or just‑in‑time approval step occurs.
The solution is a Layer 7 gateway that sits between the identity provider and the GCP resource. The gateway receives the OIDC token, validates the identity, and then proxies the protocol‑level traffic to the target service. Because all traffic passes through this gateway, it becomes the only place where enforcement can happen.
hoop.dev satisfies the three attribution categories. First, the setup, OIDC or SAML integration, service‑account role bindings, and least‑privilege IAM policies, determines who may start a request. Second, the data path is the gateway itself; every request and response traverses this path. Third, the enforcement outcomes, recording each session, applying inline data masking, requiring just‑in‑time approvals, and blocking disallowed commands, exist because hoop.dev sits in the data path. If the gateway were removed, none of those outcomes would be produced.
When a CI job needs to query a Cloud SQL instance, the job presents its service‑account token to hoop.dev. The gateway checks the token against policy, may require a human approver for a high‑risk query, masks columns such as credit‑card numbers in the response, and records the entire interaction as a replayable session. The same flow works for GKE exec sessions, Cloud Storage object reads, or Pub/Sub publish calls. All of these actions log the identity, timestamp, and policy decision, providing the concrete evidence auditors look for under SOC 2’s logical and physical access controls.
Because hoop.dev records logs in a location separate from the target service, the audit trail stays reliable even if the workload is compromised. The logs are searchable, can be exported to a SIEM, and include the approval metadata required for change‑management evidence.
Mapping hoop.dev capabilities to SOC 2 trust service criteria
- Access control (CC6.1, CC6.2): Policies enforce least‑privilege scopes and require just‑in‑time approvals for privileged operations.
- Audit logging (CC7.1, CC7.2): Every session records identity, request details, and outcome, providing an immutable audit trail.
- Change management (CC8.1): Approval workflows capture who authorized a change before execution.
- Confidentiality (CC5.1): Inline masking redacts sensitive data in responses before it reaches downstream logs.
These artifacts generate automatically, so the organization can hand auditors a single source of truth that covers multiple SOC 2 criteria.
Getting started with hoop.dev on GCP
The gateway is open source and can be deployed with Docker Compose for a quick proof of concept, or via Helm for production clusters. The getting started guide walks you through installing the agent near your GCP resources, configuring OIDC authentication, and defining policies for service accounts. For deeper insight into masking, approvals, and session replay, explore the feature documentation. All configuration expresses as declarative policy files, keeping the enforcement logic separate from the workloads that consume it.
FAQ
Does hoop.dev replace GCP’s native audit logs?
No. hoop.dev complements GCP logging by providing a centralized, policy‑driven audit trail that includes approval decisions and masked data. You can still forward GCP logs to your SIEM for a complete view.
Can hoop.dev enforce policies on existing workloads without code changes?
Yes. Because the gateway works at the protocol layer, existing clients (psql, kubectl, gsutil, etc.) continue to operate unchanged; the enforcement happens transparently in the data path.
Is hoop.dev suitable for high‑throughput production environments?
hoop.dev scales horizontally. Deploy multiple gateway instances behind a load balancer, and the agent pool routes connections efficiently while preserving the same enforcement guarantees.
Ready to see the code in action? Explore the source on GitHub and start building SOC 2‑ready machine‑identity governance today.
