Many assume that enabling session recording for an MCP server that talks to an EKS cluster is as simple as toggling a flag in the Kubernetes API. The reality is that the API server does not see who issued a command, nor does it retain a replayable log of the interaction. Without a dedicated data‑path component, session recording cannot be guaranteed.
In most teams, an MCP server is given a long‑lived kubeconfig that contains a static token or a service‑account key. That credential is copied into CI pipelines, shared among developers, and sometimes embedded in container images. The server connects directly to the EKS control plane, executes kubectl exec or kubectl apply commands, and the cluster never records who issued each line. If a breach occurs, there is no reliable evidence of what was run, and any sensitive response data streams straight to the server without filtering.
What engineers really need is a way to capture every command that an MCP server runs against an EKS cluster, while still allowing the server to function as normal. The request still reaches the Kubernetes API directly, which means the cluster itself does not provide any audit trail, no inline masking of secrets, and no way to pause a dangerous operation for human approval. The missing piece is a gateway that sits between the MCP server and the cluster, inspecting traffic before it reaches the API.
How hoop.dev enables session recording for EKS
hoop.dev acts as a Layer 7 gateway that intercepts the TCP stream carrying the Kubernetes protocol. The gateway runs an agent inside the same network as the EKS control plane. That agent assumes a dedicated IAM role configured for the connection; the role is mapped to a Kubernetes RBAC binding that grants only the permissions needed for the current session. When an MCP server initiates a connection, it authenticates to hoop.dev via OIDC, and the gateway validates the token before allowing traffic to pass.
Because the gateway is the only place where the request can be examined, hoop.dev can record each command, store the full request and response payloads, and replay the session later. It also applies inline masking to any fields that match a configured pattern, ensuring that secrets never leave the gateway in clear text. If a command matches a high‑risk rule, hoop.dev can pause execution and route the request to an approval workflow before it reaches the cluster.
Why the data path matters
The setup phase, creating OIDC clients, provisioning IAM roles, and defining Kubernetes RBAC, decides who may start a session. That identity layer alone does not enforce any policy. The enforcement outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, exist only because hoop.dev sits in the data path. Removing hoop.dev would revert the system to the original state where the MCP server talks straight to the API without any guardrails.
Key architectural components
- Identity (setup): Users and agents obtain OIDC tokens from an identity provider. The token includes group membership that hoop.dev uses to look up allowed actions.
- Gateway (data path): hoop.dev receives the connection, validates the token, and forwards the traffic to the EKS API. The agent inside the gateway assumes the configured IAM role, which is linked to a Kubernetes ClusterRoleBinding.
- Enforcement outcomes: While traffic flows through hoop.dev, every kubectl command is recorded, responses are masked according to policy, and risky operations are held for approval. The recorded session can be replayed for forensic analysis.
Getting started with session recording
Deploy the gateway using the official hoop.dev getting started guide. The quick‑start creates a Docker Compose deployment that runs the gateway and the network‑resident agent. Register an EKS connection in the UI, provide the IAM role ARN that the agent should assume, and map that role to a Kubernetes RBAC binding. Enable the session recording toggle for the connection. Once the gateway is running, point your MCP server’s kubeconfig at the gateway endpoint instead of the raw cluster URL. From that point forward, every command the server issues is captured by hoop.dev.
For deeper details on masking policies, approval workflows, and replay tooling, consult the hoop.dev feature documentation. The docs include guidance on designing least‑privilege RBAC bindings that align with your organization’s compliance requirements.
Explore the source code, contribute improvements, and see the full implementation on GitHub.
FAQ
Does using hoop.dev require changes to my existing kubeconfig?
No. The gateway is transparent to the client. You simply point the kubeconfig’s server field at the hoop.dev endpoint; the rest of the file remains unchanged.
How long are recorded sessions retained?
Retention is defined by your organization’s policy. hoop.dev stores the raw request and response logs for as long as you configure, making them available for audits or incident investigations.
Can I still use native kubectl features like kubectl exec?
Yes. Because hoop.dev operates at the protocol layer, all standard kubectl commands work as they normally would, with the added benefit that each interaction is recorded and can be masked or approved according to policy.
