How can you trust that every privileged session recording is captured and replayable when you run your own gateway? In a self‑hosted environment the temptation is to rely on ad‑hoc log files, temporary console output, or the built‑in audit features of individual services. Those approaches scatter evidence, make attribution hard, and often disappear when a node is rebuilt.
Most teams start with a shared service account or a static credential that a few engineers use to reach databases, Kubernetes clusters, or SSH hosts. The connection goes straight from the client to the target, and the only record is whatever the target writes to its own log. If a breach occurs, there is no unified view of what commands were run or what data was returned.
The missing piece is a control surface that sits on the traffic path, records every byte, and ties each action to a verified identity. Without that surface the request still reaches the target directly, there is no guaranteed audit trail, no replay capability, and no way to enforce retention or protection policies on the recorded data.
hoop.dev provides that surface. It acts as a Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, and HTTP services. Because the gateway sits in the data path, it can record each session, store the stream using its built‑in persistence, and make the recording available for replay or forensic analysis.
When a user authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and then establishes a proxied connection on behalf of the user. The gateway inspects the protocol, writes the full request‑response exchange to its internal audit store, and tags each entry with the user’s identity, timestamp, and target endpoint. The result is a complete, searchable session record that can be replayed exactly as it occurred.
Centralize recording for consistent evidence
All supported protocols – PostgreSQL, MySQL, SSH, Kubernetes exec, HTTP APIs, and others – are funneled through the same gateway. This guarantees that every interaction, regardless of target type, is captured in the same format and attached to the same identity context.
Persist recordings reliably
hoop.dev writes each session to its own audit store, which is managed as part of the self‑hosted deployment. Because the storage is part of the gateway’s controlled environment, recordings survive node restarts and can be backed up using your organization’s standard backup procedures.
Define clear retention and protection policies
Establish a retention schedule that meets regulatory and business requirements. hoop.dev can be configured to automatically expire recordings after a defined period, so old data is removed without manual effort. Retention settings are enforced centrally, ensuring consistent handling of all recorded sessions.
Restrict replay access to authorized roles
Not every engineer needs to watch a replay. Use the same identity provider that authenticates users to enforce role‑based access to the replay UI. hoop.dev checks the caller’s groups before serving a recorded session, ensuring that only auditors, incident responders, or privileged reviewers can view sensitive data.
Tie recordings to identity for clear attribution
Because hoop.dev validates the user’s OIDC token at connection time, every recorded line includes the user’s unique identifier. This attribution eliminates ambiguity when multiple engineers share a service account, and it satisfies audit requirements that demand per‑user evidence.
Start with the official getting‑started guide
For a self‑hosted deployment, follow the step‑by‑step instructions in the getting‑started documentation. The guide walks you through deploying the gateway, configuring audit storage, and enabling session recording for your chosen targets.
Deep‑dive into policy configuration
The learn section contains detailed articles on masking, just‑in‑time approvals, and fine‑grained replay permissions. Reviewing these resources helps you align hoop.dev’s capabilities with your organization’s security posture.
Explore the source code, contribute improvements, or file an issue on the project’s GitHub repository: hoop.dev on GitHub.
FAQ
- Why is a central gateway better than relying on individual service logs? A central gateway captures the full request‑response flow for every protocol, provides uniform attribution, and stores the data in a location you control. Individual service logs may miss network‑level details, lack consistent formatting, and are often tied to the lifecycle of the service node.
- How does hoop.dev ensure recordings cannot be altered after the fact? Recordings are written to hoop.dev’s audit store, which you manage and protect with your organization’s standard integrity controls. By restricting write access to the store, you can detect any unauthorized modifications.
- Can I limit who can replay a session? Yes. Replay access is governed by the same OIDC groups used for authentication. Only users with the designated replay role can request a playback, and the gateway enforces that check before serving the data.
