A fully auditable, just‑in‑time governed machine access pipeline on Azure meets every NIST control without exposing secrets. In that ideal world, every service account, automation token, or container identity is issued on demand, its usage is recorded, and any privileged operation is either approved or blocked before it reaches the target system.
What NIST expects for non‑human identities
The NIST SP 800‑53 family defines a set of controls that apply to all information system components, including those that act without a human at the keyboard. Key requirements for non‑human identities include:
- AC‑2 (Account Management): Accounts must be provisioned, reviewed, and disabled in a timely manner.
- IA‑2 (Identification and Authentication): Each machine identity must be uniquely tied to an entity and use cryptographic authentication.
- AU‑6 (Audit Review, Analysis, and Reporting): Actions performed by service accounts must be logged and reviewed for suspicious activity.
- CM‑7 (Least Functionality): Access must be limited to the minimum set of functions required for the task.
- IR‑4 (Incident Handling): Evidence of machine‑initiated actions must be available to support investigations.
Collectively, these controls demand a lifecycle that starts with identity issuance, continues with precise authorization, and ends with immutable evidence that shows who did what, when, and why.
Why the current approach falls short
Most Azure teams rely on static service‑principal passwords or long‑lived managed identities that are embedded in scripts, CI pipelines, or container images. The typical flow looks like this:
- A developer creates a service principal, grants it broad role‑based access, and stores the secret in a repository.
- Automation jobs retrieve the secret and connect directly to Azure resources, databases, or Kubernetes clusters.
- All traffic flows straight to the target; the gateway that could enforce policies is bypassed.
- Logs are either missing or limited to the Azure platform’s basic audit, which does not capture command‑level detail or response data.
Even when teams move to Azure‑managed identities, the identity is still presented directly to the resource. The request reaches the target without an intervening control point that could inspect the payload, enforce just‑in‑time approval, or mask sensitive fields. Consequently, the environment satisfies the provisioning part of AC‑2 but fails the audit, least‑functionality, and incident‑handling requirements that NIST mandates.
How hoop.dev provides the required evidence
hoop.dev introduces a Layer 7 gateway that sits between every non‑human identity and the Azure resources it must access. By placing enforcement in the data path, hoop.dev can satisfy each of the NIST controls listed above:
- Session recording: hoop.dev records every connection, command, and response. The recorded session becomes immutable evidence for AU‑6 and IR‑4.
- Just‑in‑time approval: Before a privileged operation is sent to the target, hoop.dev checks the request against policy. If the operation exceeds the allowed scope, hoop.dev routes it for human approval or blocks it outright, satisfying CM‑7.
- Inline masking: Sensitive data that appears in responses, such as passwords or personal identifiers, can be masked by hoop.dev before it reaches the calling service, reducing the risk of credential leakage.
- Dynamic credential handling: The gateway holds the actual Azure credential. Service accounts never see the secret; they present a short‑lived token that hoop.dev validates against the OIDC provider. This aligns with IA‑2 and supports the principle of least privilege.
- Audit aggregation: hoop.dev centralises logs from databases, Kubernetes, SSH, and HTTP services, providing a single source of truth that auditors can query for AU‑6 compliance.
Because hoop.dev is the only component that can inspect traffic at the protocol level, the enforcement outcomes exist only because the gateway is in place. Removing hoop.dev would revert the system to the insecure direct‑connect model described earlier.
Getting started on Azure
Deploy the hoop.dev gateway in the same virtual network as your Azure resources. The quick‑start guide walks you through a Docker‑Compose deployment, OIDC configuration with Azure AD, and registration of a sample Azure SQL Database connection. Once the gateway is running, update your automation scripts to point at the hoop.dev endpoint instead of the native Azure endpoint. Detailed steps are available in the getting‑started guide and the broader learn section.
FAQ
Does hoop.dev replace Azure AD or Azure RBAC? No. hoop.dev consumes Azure AD tokens to authenticate the caller and then enforces additional guardrails on the traffic. Azure RBAC still governs the underlying resource permissions.
Can hoop.dev work with existing service principals? Yes. Existing service principals can be mapped to hoop.dev connections, but the gateway will still be the point where session recording and approval happen.
What evidence does hoop.dev generate for auditors? It produces per‑session logs that include identity, timestamp, command text, and any masking applied. Those logs can be exported to SIEMs or retained for the audit period required by NIST.
Explore the open‑source code on GitHub: https://github.com/hoophq/hoop.
