PCI DSS for non-human identities: governing machine access end to end (on Kubernetes)

Why machine identities are a PCI DSS blind spot

A compromised service account can expose every cardholder data record in a PCI‑DSS environment. In many Kubernetes clusters, engineers create long‑lived service account tokens, embed them in container images, and grant those accounts cluster‑wide permissions. The result is a credential that can be copied, reused, and never rotated. Auditors looking for “restrict access to cardholder data” quickly discover that the same token is used by dozens of micro‑services, often with admin‑level RBAC.

The standard also requires that every access to systems handling cardholder data be logged and that logs be immutable for at least one year. When a pod runs with a static token, the Kubernetes API server writes an audit entry, but the entry only contains the service account name – it does not capture the exact command, the data returned, or any downstream request to a database. Moreover, most clusters do not enable request‑level masking, so a compromised service can read unredacted credit‑card numbers from a database response.

PCI DSS expectations for non‑human identities

PCI DSS v4.0 specifies several controls that directly affect machine‑to‑machine traffic:

• Requirement 8.5: Enforce least privilege for all accounts, including service accounts.
• Requirement 10.2: Log all access to system components handling cardholder data.
• Requirement 10.5: Protect log integrity and retain logs for at least one year.
• Requirement 3.4: Mask PAN when displayed or transmitted to non‑authorized entities.

In practice, teams can meet the first bullet by tightening RBAC, but the remaining three still rely on a data path that can enforce them. The missing piece is a gateway that can inspect each request, record the full session, and apply inline masking before the data ever reaches the service.

The precondition: least‑privilege tokens without a control plane

Most organizations have already moved the identity source to OIDC or to Kubernetes service accounts that are scoped to a namespace. Those tokens are now the entry point for machines, and they satisfy the “who is requesting” part of PCI DSS. However, the request still travels straight to the Kubernetes API server and then to the target pod. No component in that path can:

• Require a human approval step for high‑risk operations such as creating a new secret.
• Mask credit‑card fields in API responses before they are logged or displayed.
• Record the exact kubectl command, the arguments, and the response payload for later audit.
• Block dangerous commands like "kubectl exec --stdin --tty" that could be used for lateral movement.

In short, the setup provides identity and basic RBAC, but it leaves the data path wide open. PCI DSS still considers that a gap because the standard expects “full‑session logging” and “data protection at the point of access”.

hoop.dev as the enforced data path

hoop.dev solves the gap by inserting a Layer 7 gateway between the service account and the Kubernetes API server. The gateway runs an agent inside the cluster, proxies every request, and enforces policies before the request reaches the target pod.

Because hoop.dev is the only point that can see the full request and response, it can provide the enforcement outcomes PCI DSS demands:

• Session recording: hoop.dev records each kubectl command, the full request payload, and the response. The recordings are stored in an audit log that satisfies log‑integrity requirements.
• Inline masking: When a response contains a PAN, hoop.dev masks the digits according to the masking rule before the data is written to any downstream log or displayed to a user.
• Just‑in‑time approval: High‑risk actions such as creating a secret or executing a privileged pod trigger a workflow that requires an authorized human to approve the request.
• Command blocking: Dangerous kubectl verbs (e.g., exec, port‑forward) can be denied automatically unless an explicit approval is present.
• Access scoping: The gateway enforces per‑service‑account policies that limit which namespaces and resources a machine can touch, fulfilling the least‑privilege requirement.

All of these outcomes are possible only because hoop.dev sits in the data path. The identity verification that happens upstream – the OIDC token, the service‑account claim – merely tells the gateway who is making the request. The enforcement itself happens inside hoop.dev, not in the Kubernetes API server or the target workload.

Implementing a PCI‑DSS‑ready pipeline

To align a Kubernetes deployment with PCI DSS using hoop.dev, follow the high‑level steps below. The detailed configuration lives in the getting started guide and the broader feature documentation.

1. Deploy the hoop.dev gateway in the same network as the cluster. The official Docker‑Compose quick‑start provides a minimal, production‑ready deployment.
2. Register each Kubernetes API endpoint as a connection in hoop.dev, attaching the service‑account token that the workload will use.
3. Define policy rules that map service‑account identities to allowed namespaces, verbs, and resource types. Include masking rules for fields that contain PAN.
4. Enable the just‑in‑time approval workflow for any rule that creates or updates secrets.
5. Configure the audit sink to forward session recordings to your SIEM or log‑retention system for a one‑year retention period.

Once the gateway is in place, every machine‑initiated request passes through hoop.dev, guaranteeing that the PCI DSS controls are enforced consistently.

FAQ

Q: Does hoop.dev replace Kubernetes RBAC?
A: No. hoop.dev complements RBAC by adding session‑level enforcement and logging. Existing role bindings remain in effect; hoop.dev adds an additional guardrail.

Q: Can I use hoop.dev with existing service‑account tokens?
A: Yes. The gateway accepts any OIDC‑compatible token. You simply register the token with the connection definition.

Q: How does hoop.dev help with log retention for PCI DSS?
A: The gateway writes session logs that can be streamed to any storage backend you choose. Because the logs contain the full request and response, they satisfy the “retain detailed audit logs” requirement.

For a hands‑on look at the source code and to contribute, visit the GitHub repository.