An offboarded contractor’s service account still holds a long‑lived API key that drives automated data transfers between internal services. The key lives in a CI configuration file, is shared among several pipelines, and never expires. Relying on static credentials defeats just-in-time access principles. When the contractor leaves, the key remains active, giving any attacker who discovers it unrestricted access to the same back‑end systems.
This is the reality for many organizations that rely on application‑to‑application (A2A) communication. Service accounts, static credentials, and broad IAM tokens are convenient, but they create a permanent trust relationship that is hard to audit and impossible to revoke without breaking downstream jobs.
Why just-in-time access matters for A2A
Just-in-time access reduces the window of exposure by issuing short‑lived, purpose‑bound permissions at the moment a request is made. It forces the identity system to evaluate who is asking, why they need the resource, and whether the request complies with policy before the connection is allowed.
In an A2A world the request is usually made by a non‑human identity: a CI job, a microservice, or an automated script. The identity layer can enforce least‑privilege grants, but without a control point on the data path the request still reaches the target directly. That means there is no guarantee that the request was approved, that sensitive fields were masked, or that the action was recorded for later review.
Implementing just-in-time access with hoop.dev
hoop.dev provides the missing data‑path enforcement. It sits as a Layer 7 gateway between the service identity and the target infrastructure, whether the target is a database, a Kubernetes API, an SSH host, or an internal HTTP endpoint. Because the gateway inspects traffic at the protocol level, it can enforce just-in-time policies, require human approval for risky commands, mask confidential fields in responses, and record the entire session for replay.
When a CI job or microservice initiates a connection, the following flow occurs:
- The request is authenticated against an OIDC or SAML provider. hoop.dev validates the token and extracts group membership.
- Based on the identity and the requested operation, hoop.dev checks a policy that may grant a short‑lived credential, require an approval step, or deny the request outright.
- If approved, hoop.dev proxies the traffic to the target, applying inline masking and command‑level guards as defined.
- The session is recorded and stored for audit, providing evidence that satisfies compliance programs.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. The setup, OIDC federation, role‑based service accounts, and network placement, decides who may start a request, but without hoop.dev the request would flow straight to the resource with no guardrails.
Best‑practice checklist
- Define non‑human identities clearly. Use distinct service accounts for each integration and bind them to OIDC groups that reflect the business purpose.
- Enforce least‑privilege scopes. Grant each service account only the permissions required for its specific A2A flow, and no more.
- Deploy hoop.dev as the sole entry point. All database, Kubernetes, SSH, or HTTP calls must go through the gateway. This creates a single enforcement surface.
- Enable just‑in‑time credential issuance. Configure policies that issue short‑lived tokens at request time rather than storing static passwords.
- Require approval for high‑risk actions. For commands that alter schema, delete data, or change cluster configuration, set a workflow that pauses the request for human review.
- Mask sensitive response fields. Identify columns such as credit‑card numbers or personal identifiers and configure hoop.dev to redact them before they reach the calling service.
- Record every session. Turn on session logging so that each interaction can be replayed for forensic analysis or compliance audits.
- Integrate with existing CI/CD pipelines. Point your pipeline’s client tools (psql, kubectl, ssh) at the hoop.dev endpoint; the gateway handles the rest.
For step‑by‑step guidance on deploying the gateway and registering A2A connections, see the getting started guide and the broader learn page. Both pages cover network placement, OIDC configuration, and policy authoring.
FAQ
How does just‑in‑time access differ from rotating static service keys?
Rotating static keys still leaves a credential that any holder can reuse until it expires. Just‑in‑time access generates a fresh, purpose‑bound credential for each request, and the gateway can deny or approve the request in real time.
Can hoop.dev be added to an existing CI pipeline without rewriting code?
Yes. Because hoop.dev proxies standard protocols, you only need to change the endpoint address in your pipeline configuration. The underlying client tools remain unchanged.
Explore the source code, contribute improvements, or file issues on the GitHub repository.
