How can you enforce fine‑grained iam for short‑lived agents without scattering secrets across the fleet?
Most teams start by baking static credentials into container images or granting a single service account cluster‑wide access. A Python script that talks to a database may run with a root‑level PostgreSQL user, while a Go microservice that only needs read‑only metrics uses the same secret. Engineers copy keys between environments, rotate them manually, and rely on ad‑hoc documentation to remember who can do what. The result is a sprawling surface of over‑privileged identities, no visibility into which runtime issued which command, and an audit trail that ends at the point where the process exits.
Even when organizations adopt OIDC or SAML to issue short‑lived tokens, the core problem remains: the runtime still connects directly to the target system. The token proves identity, but the connection bypasses any centralized enforcement. There is no place to inspect a SQL statement before it reaches the database, no hook to require a human approval for a dangerous Kubernetes exec, and no automatic recording of the session for later review. In other words, the setup fixes identity provenance but leaves the data path wide open.
Why the data path matters for iam
Identity‑aware access control must be enforced where the request actually travels. If the enforcement point is outside the process that holds the credential, you gain three essential properties:
- Policy enforcement cannot be tampered with by the runtime itself.
- Every request can be inspected, logged, and, if needed, altered before it reaches the target.
- Sensitive response fields can be masked in real time, protecting downstream consumers.
These properties are impossible to guarantee when the runtime talks straight to the database, SSH daemon, or HTTP service. The only reliable way to insert a guardrail is to place a gateway between the two.
Introducing hoop.dev as the enforcement layer
hoop.dev is a layer‑7 gateway that sits between agent runtimes and the infrastructure they need to reach. It authenticates each request against your OIDC or SAML provider, extracts group membership, and then applies fine‑grained iam policies before proxying the traffic. Because the gateway lives on the network, not inside the container, the runtime never sees the target credentials; hoop.dev holds them and presents them only after the request has been authorized.
Once a request passes the gateway, hoop.dev can:
- Record each session. hoop.dev writes a timestamped audit record for every command, query, or file transfer, preserving a replayable log.
- Mask sensitive data. Responses that contain passwords, tokens, or personal identifiers are filtered in real time, ensuring downstream tools never expose secrets.
- Block disallowed commands. hoop.dev rejects SQL statements that match a deny list, prevents destructive Kubernetes exec calls, and stops SSH commands that violate your policy.
- Require just‑in‑time approval. For high‑risk actions, hoop.dev routes the request to an approver before forwarding it, turning ad‑hoc manual checks into a repeatable workflow.
All of these outcomes exist only because hoop.dev occupies the data path. If you removed the gateway, the runtime would again have unfettered access and none of the above protections would apply.
Putting the pieces together
The overall architecture consists of three layers:
- Setup. Define OIDC clients, provision service accounts, and assign least‑privilege roles in your identity provider. This step decides who can request access, but it does not enforce any action.
- The data path. Deploy hoop.dev as a network‑resident agent that proxies connections to databases, SSH, or HTTP services. All traffic flows through this gateway.
- Enforcement outcomes. hoop.dev records sessions, masks data, blocks commands, and triggers approval workflows. These outcomes are the measurable security benefits you gain.
By separating identity provenance (setup) from enforcement (data path), you achieve a clean security boundary that can be audited and evolved independently of the workloads that use it.
Getting started
Begin with the getting‑started guide to spin up a local gateway and register a test database. The learn section provides deeper coverage of policy definition, just‑in‑time approval flows, and session replay. Both resources assume you have an OIDC provider already configured, which satisfies the setup layer described earlier.
FAQ
Do I need to change my application code?
No. Agent runtimes continue to use their native clients (psql, kubectl, ssh, etc.). The only change is the endpoint they point at – the gateway address instead of the direct target.
What happens to existing credentials?
Credentials are moved into hoop.dev’s secret store. The runtime never receives them; the gateway presents them after successful iam checks.
Can I still use role‑based access control inside the target?
Yes. hoop.dev works alongside native RBAC. It adds an extra layer that can enforce policies that the target itself does not understand, such as masking specific columns in query results.
Explore the source
hoop.dev is open source and MIT licensed. To examine the implementation, contribute, or fork the project, visit the GitHub repository.
