A single mis‑configured service account can expose protected health information across an entire cluster.
HIPAA expects every entity that can read, create, or transmit electronic PHI to be tightly controlled, auditable, and limited to the minimum functions required for its business purpose. The rulebook talks about "access control" and "audit controls" in a way that applies not only to human users but also to the machines, containers, and automated jobs that move data behind the scenes. In practice, teams often treat service accounts like static passwords: they are created once, stored in plain text, and shared across dozens of pods. When a vulnerability is discovered, the blast radius can be massive because the same credential is used everywhere.
HIPAA also requires that every access to PHI be logged with enough detail to reconstruct who, or what, performed an action, when it happened, and why it was allowed. The standard does not prescribe a particular logging format, but it does demand that the logs be immutable, retained for at least six years, and accessible for audit. For non‑human identities, this means capturing the identity of the service account, the pod or container that presented it, and the exact API call or command that touched PHI.
Another cornerstone of HIPAA is the principle of least privilege. Each machine identity should have only the permissions necessary to perform its intended workload. Over‑privileged pods can become a conduit for lateral movement, allowing an attacker who compromises one component to reach databases, object stores, or other services that hold PHI. The standard also calls for periodic reviews of access rights, yet many organizations lack a systematic way to verify that a service account’s permissions still match its job description.
Finally, HIPAA mandates that any change to access rights be authorized and documented. When a new microservice is deployed, a human must approve the grant of any PHI‑related capabilities. Without a workflow that captures that approval, the organization cannot demonstrate compliance during an audit.
Why the data path matters for machine‑to‑machine governance
All of the controls above can be described in policy, but they only become effective when they are enforced at the point where traffic actually flows. Authentication and role assignment happen upstream, but without a gate in the data path there is nothing to stop a privileged service account from reaching a database directly. Likewise, logging that occurs after the fact in the application layer can be tampered with by the same compromised process that issued the request.
Placing a gateway at Layer 7 gives a single place to inspect, authorize, and record every request, regardless of which pod or service originated it. That gateway can see the full protocol, apply real‑time masking to any PHI that appears in responses, and enforce just‑in‑time approval before a risky operation proceeds.
How hoop.dev satisfies hipaa evidence requirements on Kubernetes
hoop.dev inserts a Layer 7 gateway between non‑human identities and the Kubernetes cluster. The gateway runs as a network‑resident agent that proxies all connections to the API server, exec sessions, and port‑forward streams. Because every request passes through the gateway, hoop.dev can generate the evidence HIPAA expects.
- Session recording. hoop.dev records each command, the identity of the service account that issued it, and the full response payload. The recordings are stored outside the pod that executed the command, making them tamper‑evident and available for the six‑year retention window.
- Inline masking. When a response contains PHI, hoop.dev can mask or redact the sensitive fields before they reach the calling container. This satisfies the "minimum necessary" rule while still allowing the application to function.
- Just‑in‑time approval. For operations that are deemed high risk, such as creating a new PersistentVolumeClaim that could store PHI, hoop.dev can pause the request and route it to a human approver. The approval decision is logged alongside the session.
- Command‑level audit. hoop.dev logs the exact API verb, resource name, and namespace, tying the activity to the specific service account and pod. Auditors can query these logs to prove who accessed what and when.
- Least‑privilege enforcement. By integrating with Kubernetes RBAC, hoop.dev can reject any request that exceeds the permissions granted to the service account, preventing accidental over‑privilege.
All of these outcomes exist because hoop.dev sits in the data path. The upstream identity provider (Okta, Azure AD, etc.) supplies the service‑account token, but without hoop.dev the token would travel straight to the API server, bypassing any of the controls above.
Implementing hipaa‑ready machine access on Kubernetes
Start by deploying the hoop.dev gateway using the official getting‑started guide. The deployment includes an OIDC configuration that validates service‑account tokens issued by your identity provider. Once the gateway is running, register each Kubernetes API endpoint you want to protect. The gateway stores the credentials needed to talk to the API server, so pods never see them directly.
Next, define the masking policies that identify PHI in API responses. The policy language lets you specify JSON paths or regular expressions that match protected fields. When a response matches, hoop.dev redacts the data before it reaches the pod.
Finally, configure the approval workflow for high‑risk verbs. The workflow can be integrated with existing ticketing or chat tools, ensuring that a human signs off before the operation is allowed.
For detailed steps on each of these pieces, see the getting‑started documentation and the broader learn portal. The repository on GitHub contains the full source and example configurations.
Explore the open‑source code and contribute on GitHub: https://github.com/hoophq/hoop.
FAQ
Does hoop.dev replace Kubernetes RBAC?
No. hoop.dev works alongside RBAC. It enforces the same role checks but adds audit, masking, and approval capabilities that RBAC alone does not provide.
How long are the session recordings retained?
Retention is configurable, but the default setup aligns with HIPAA’s six‑year requirement. Recordings are stored outside the cluster to prevent tampering.
Can hoop.dev be used with other orchestrators?
The gateway model is generic, but the current open‑source release focuses on Kubernetes. Support for additional orchestrators may be added in future releases.
By placing a Layer 7 gateway in the data path, hoop.dev turns the abstract HIPAA controls for non‑human identities into concrete, observable evidence. This approach lets organizations demonstrate compliance without relying on fragile, ad‑hoc logging or over‑privileged service accounts.
