Running critical services behind a self‑hosted gateway sounds safe, until a single over‑privileged credential lets an attacker move laterally.
Why policy enforcement is hard in self‑hosted models
Most teams deploy a self‑hosted agent or proxy next to a database, Kubernetes cluster, or SSH endpoint. The agent is usually started with a static password, a long‑lived SSH key, or a service account that has broad read‑write rights. Engineers share those secrets in chat, embed them in CI pipelines, and rarely rotate them. The result is a world where anyone who can reach the network can issue any command, extract raw data, or modify configuration without a single audit record.
Even when organizations add an identity layer, OIDC, SAML, or a cloud‑native IAM role, the request still travels straight to the target. The identity check tells the system *who* is asking, but there is no place on the path to verify *what* they are allowed to do, *whether* the command should be recorded, or *if* sensitive fields need to be hidden. The enforcement point is missing.
The missing enforcement layer
Self‑hosted models typically rely on three separate pieces:
- Setup: provisioning users, assigning groups, and issuing tokens. This decides who may start a connection.
- Direct connection: the request goes straight from the client to the target service.
- Post‑hoc monitoring: logs are collected after the fact, often incomplete and hard to correlate with individual users.
Because the gateway sits only at the edges of the network, it cannot inspect protocol payloads, block dangerous commands, or mask data in real time. The result is a gap where policy enforcement, command‑level audit, just‑in‑time approval, inline masking, and session replay, cannot be guaranteed.
Introducing an identity‑aware gateway as the data path
To close that gap, the enforcement point must sit in the data path, between the authenticated identity and the target resource. hoop.dev provides exactly that: a Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, RDP, and HTTP services. Because every request passes through the gateway, hoop.dev can apply policy enforcement consistently.
When a user presents an OIDC token, hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed. If the request is allowed, hoop.dev forwards it to the target; if not, it blocks the command before it reaches the service. For operations that require human oversight, such as dropping a production table, hoop.dev can pause the request and trigger an approval workflow.
All traffic is inspected at the protocol layer, so hoop.dev can mask sensitive columns in a database response, redact secret fields in logs, and record every keystroke or API call. The recorded session can be replayed later for forensic analysis, providing a reliable audit trail that ties each action to a specific identity.
How the enforcement outcomes are achieved
Because hoop.dev is the only component that sees the full payload, it alone can guarantee the following outcomes:
- Command‑level audit: every query or shell command is logged with the user’s identity.
- Inline data masking: sensitive fields are redacted before they leave the target.
- Just‑in‑time approval: risky operations are held for manual sign‑off.
- Session recording and replay: a complete video‑like record can be reviewed after the fact.
These capabilities exist only because hoop.dev occupies the data path. If you removed hoop.dev and left only the setup and direct connection, none of the above would be enforceable.
Getting started with a self‑hosted gateway
Deploying hoop.dev is straightforward. The official getting started guide walks you through a Docker Compose launch, OIDC configuration, and registering a target such as PostgreSQL or an SSH host. Once the gateway is running, existing client tools (psql, kubectl, ssh) work without modification; they simply point at the hoop.dev endpoint.
Because hoop.dev is open source and MIT‑licensed, you can host it in any environment, on‑premises, in a private cloud, or inside a Kubernetes cluster. The same policy enforcement guarantees apply regardless of where you run it.
FAQ
Is hoop.dev a replacement for my existing IAM system?
No. hoop.dev consumes the identity tokens issued by your IAM provider. It does not replace authentication; it adds enforcement where your IAM stops.
Can I use hoop.dev with multiple cloud providers?
Yes. The gateway proxies connections to any supported target, whether it lives in AWS, Azure, GCP, or on‑premises. The enforcement logic is independent of the underlying cloud.
What happens if the gateway itself is compromised?
Because hoop.dev never stores user credentials and records every session, any misuse can be detected in the audit logs. Deploying the gateway in a hardened segment and monitoring its own logs further reduces risk.
Policy enforcement in self‑hosted models requires a dedicated, protocol‑aware gateway. By placing hoop.dev in the data path, you gain real‑time control, auditability, and data protection that pure identity setup cannot provide.
View the open‑source repository on GitHub to explore the code, contribute, or spin up your own instance.
