What NIST says about machine identities
NIST SP 800‑53 and the newer SP 800‑53 Rev. 5 treat non‑human identities, service accounts, CI/CD tokens, and automated agents, as full‑blown actors that must be governed with the same rigor as human users. The standard requires explicit identification, least‑privilege authorisation, continuous monitoring, and immutable evidence of every privileged operation. When a machine talks to a Kubernetes API server, NIST expects the request to be traceable to a specific identity, that the identity only has the permissions needed for that task, and that the organisation can prove who approved the action and what data was returned.
Why the usual approach falls short
Most teams grant service accounts broad cluster‑role bindings and store their credentials in plain‑text secrets. The agents that use those secrets connect directly to the API server, bypassing any central gatekeeper. This model satisfies the identity‑verification step, because the token is valid, but it fails to provide the continuous monitoring and audit trail NIST demands. Without a point of inspection, risky commands run unchecked, secret values leak in logs, and there is no way to retroactively prove that a particular deployment was approved by an authorised human.
Putting the control point in the data path
hoop.dev inserts an identity‑aware proxy between the non‑human identity and the Kubernetes control plane. The proxy runs as a network‑resident agent, receives the request, validates the caller’s OIDC token, and then enforces policy before the request reaches the API server. Because all traffic flows through this gateway, hoop.dev becomes the only place where enforcement can happen.
Session recording for audit
hoop.dev records every API call, the full request and response payload, and the identity that originated the call. Auditors can replay a session to see exactly which resources were created, modified, or deleted, satisfying NIST’s requirement for evidence of privileged actions.
Just‑in‑time approvals
When a non‑human identity attempts a high‑risk operation, such as creating a ClusterRoleBinding or exposing a secret, hoop.dev pauses the request and routes it to an approval workflow. A designated human reviewer must explicitly approve the action before it proceeds. This inline approval mechanism fulfills NIST’s mandate for documented, human‑in‑the‑loop authorisation for sensitive operations.
Inline masking of secrets
Responses that contain credential material are inspected by hoop.dev. Sensitive fields are redacted in real time before the data reaches the calling service, preventing accidental leakage into logs or downstream systems. By masking secrets at the protocol layer, hoop.dev helps organisations meet NIST’s control that mandates protection of confidential data in transit.
How hoop.dev fits into a Kubernetes deployment
Deploy the gateway using the getting‑started guide. The agent runs on a node that has network access to the API server. Non‑human identities are provisioned in the identity provider (Okta, Azure AD, etc.) and are mapped to scoped roles inside hoop.dev. When a CI pipeline needs to apply a manifest, it authenticates to hoop.dev with its OIDC token, receives a short‑lived session, and the proxy forwards the request after applying the configured guards.
Evidence that satisfies NIST
Because hoop.dev sits in the data path, every enforcement outcome, session recordings, approval timestamps, and masked response logs, is generated by the gateway. The evidence is centrally stored and can be exported for audit purposes. Organizations can therefore demonstrate to auditors that they have:
- Identified each machine identity that performed an action.
- Enforced least‑privilege permissions at the point of request.
- Recorded logs of every privileged API call.
- Obtained documented human approvals for high‑risk operations.
- Protected sensitive data from accidental exposure.
All of these artifacts align with the control families NIST outlines for access control, audit and accountability, and system and communications protection.
FAQ
- Q: Does hoop.dev replace my existing RBAC configuration?
A: No. hoop.dev works alongside Kubernetes RBAC. It adds a runtime guard that validates the request against policy before the API server evaluates RBAC, providing an extra layer of assurance. - Q: Can I use hoop.dev with any OIDC provider?
A: Yes. hoop.dev is an OIDC relying party and can verify tokens from any standards‑compliant identity provider. The provider supplies the identity, hoop.dev supplies the enforcement. - Q: How long are the session recordings retained?
A: Retention is configurable in the gateway’s storage settings. Choose a period that satisfies your organisation’s compliance window; the data remains available for the duration of that window.
For a deeper dive into all of hoop.dev’s features, see the feature documentation.
Explore the open‑source repository on GitHub
