Machine identities that roam unchecked can silently erode SOC 2 compliance.
Why the current practice fails SOC 2 expectations
Most teams provision a service account, a static token, or a long‑lived Kubernetes secret for every automated workload. Those credentials are baked into Helm charts, stored in Git, or handed off to CI pipelines without any central review. The result is a network of standing permissions that let a pod talk to a database, a cache, or an internal API without any record of who invoked the request or why.
SOC 2’s Trust Services Criteria demand that access to critical systems be traceable, that privileged actions be reviewed, and that sensitive data be protected at the point of use. When a machine identity is used directly, none of those controls are observable. The audit trail ends at the Kubernetes API server, and the downstream service sees only a generic service‑account principal. No one can prove that a particular job was approved, that a secret field was masked, or that the command sequence was safe.
What the standard expects for non‑human identities
SOC 2 expects evidence that every privileged interaction is:
- Authenticated by a verifiable identity, not a shared secret.
- Authorized with a policy that reflects the least‑privilege principle.
- Logged in a tamper‑evident store, including the requestor, time, and outcome.
- Reviewed or approved when the action exceeds a defined risk threshold.
- Protected from leaking sensitive fields such as passwords or tokens.
These controls must be enforceable at the point where the machine actually talks to the target system. Relying on upstream Kubernetes RBAC alone leaves a gap: the gateway between the pod and the database can still be bypassed, and the downstream service cannot see the intent of the request.
How hoop.dev fulfills the SOC 2 control set
hoop.dev is a Layer 7 gateway that sits between the identity provider and the Kubernetes‑hosted resource. The setup phase creates a service‑account‑derived OIDC token that tells hoop.dev who the caller is. That token is the setup – it decides which machine identity is allowed to start a connection, but it does not enforce any policy on its own.
The gateway itself is the data path. All traffic from the pod to the target database, API, or internal HTTP service is proxied through hoop.dev. Because the gateway controls the wire‑protocol, it is the only place where enforcement can happen.
From that position hoop.dev delivers the required enforcement outcomes:
- hoop.dev records each session, capturing the full command stream and response payloads for later replay.
- hoop.dev masks sensitive fields in real time, ensuring that secrets never appear in logs or audit reports.
- hoop.dev requires just‑in‑time approval for high‑risk operations, pausing the request until an authorized human grants consent.
- hoop.dev blocks disallowed commands before they reach the backend, preventing accidental data loss or privilege escalation.
- hoop.dev tags every audit entry with the originating machine identity, the OIDC claim set, and the exact timestamp, satisfying SOC 2’s evidence requirements.
Because the gateway sits outside the workload, the agent that runs inside the customer network never sees the underlying credential. That separation guarantees that the audit trail cannot be tampered with by the very process that is being monitored.
Implementing the controls
Start by defining a minimal set of service accounts in your identity provider. Each account should map to a distinct workload and carry only the scopes it truly needs. Then register the Kubernetes service as a hoop.dev connection, pointing the gateway to the target database or API. The gateway holds the credential; the workload authenticates only with its OIDC token.
From there, configure policies that describe which commands are safe, which fields require masking, and which actions trigger an approval workflow. The policies are evaluated on every request, and any deviation is either blocked or queued for manual review. All outcomes are written to the audit store that hoop.dev maintains.
For teams that need to demonstrate SOC 2 compliance to auditors, the recorded sessions and approval logs can be exported directly from the hoop.dev UI or via the API. The exported package contains the full chain of evidence: identity, policy decision, masked response, and final status.
Getting started with hoop.dev
Follow the getting‑started guide to spin up the gateway in your environment. The documentation walks you through deploying the Docker Compose stack, registering a Kubernetes target, and defining a simple least‑privilege policy.
For deeper insight into policy language, masking options, and approval workflows, explore the learn section. Both resources are written for engineers who need to meet compliance without sacrificing automation speed.
FAQ
Does hoop.dev replace Kubernetes RBAC?
No. Kubernetes RBAC still decides which pods can request a connection. hoop.dev adds a second, enforceable layer that records, masks, and approves each request before it reaches the target.
Can I use hoop.dev with existing CI pipelines?
Yes. CI jobs authenticate with the same OIDC flow used by other workloads, and the gateway enforces the same policies, giving you uniform evidence across all automation.
What evidence does hoop.dev provide for a SOC 2 audit?
hoop.dev records immutable session logs, approval timestamps, masked response records, and identity attributes for every machine‑initiated request. Those artifacts map directly to the SOC 2 criteria for access control and auditability.
Take the next step
Review the source code, contribute improvements, or launch your own instance by visiting the repository at github.com/hoophq/hoop.
