A mature self‑hosted environment knows exactly who can touch each system, when they did it, and why the access was granted. Teams can answer audit questions without hunting through logs, and engineers never have to guess whether a colleague’s credential is still valid.
Why access reviews matter for self‑hosted models
In many organizations that run their own infrastructure, the review process is an after‑thought. Engineers share a handful of privileged passwords, store them in plain‑text notes, and rely on a spreadsheet that is updated once a quarter, if at all. When a new hire leaves, the spreadsheet is rarely edited, and the old credentials linger on servers for months. The result is a sprawling attack surface that no one can reliably inventory.
Even when a formal policy mandates quarterly access reviews, the implementation often stops at a checklist. The checklist confirms that a manager signed a document, but the actual connections still flow directly from the user’s workstation to the database or Kubernetes cluster. There is no technical enforcement that the reviewed permissions are the ones being used, no real‑time visibility into what commands were executed, and no guarantee that sensitive data was protected during the session.
What a solid foundation looks like
Effective access reviews start with three pillars:
- Identity‑driven provisioning. Each user, service account, or automation agent receives a unique identity that is tied to a least‑privilege role. The identity is issued by an OIDC or SAML provider and never shared.
- Central enforcement point. All traffic to critical resources passes through a gateway that can inspect, approve, or block operations based on policy.
- Evidence generation. Every session is recorded, every command is logged, and any sensitive fields in responses are masked before they reach the requester.
Only when these pillars are in place can an organization claim that its access reviews are enforceable, auditable, and repeatable.
Where most teams fall short
The typical self‑hosted stack lacks a dedicated enforcement point. Engineers connect directly with psql, kubectl, or ssh using credentials that were manually copied to their machines. The review process may verify that a role exists, but nothing stops a user from escalating privileges on the fly or from running a destructive command that was never approved. Because the gateway is missing, there is no place to apply inline data masking, just‑in‑time approval, or session replay.
Without a data‑path control, the organization cannot answer questions such as:
- Did anyone query a credit‑card column after the last review?
- Was a privileged command executed without a manager’s sign‑off?
- Can we replay a session to verify that a change was made according to policy?
These gaps leave the access review process brittle and prone to human error.
Introducing hoop.dev as the enforcement layer
hoop.dev positions itself as the Layer 7 gateway that sits between identities and infrastructure. It receives an OIDC token, validates the user’s groups, and then proxies the connection to the target system. Because the gateway is the only place where traffic is inspected, hoop.dev can enforce the three pillars described earlier.
Setup. Identity is handled by an external provider such as Okta or Azure AD. hoop.dev acts as a relying party, reads the token, and maps groups to fine‑grained roles. This step decides who the request is and whether it may start, but it does not enforce any policy on its own.
The data path. All database, Kubernetes, SSH, and HTTP connections are routed through hoop.dev’s agent that runs inside the customer’s network. Because the gateway is in the data path, it is the only place enforcement can happen.