Why static credentials are a liability for EKS access
Do you find yourself granting MCP servers permanent IAM roles that can reach any pod in an EKS cluster? Most teams solve the problem by creating a long‑lived service account, attaching a broad IAM policy, and letting the server use those credentials for the lifetime of the cluster. The convenience is immediate, but the trade‑off is severe: any compromise of the server gives an attacker unrestricted lateral movement, and there is no built‑in record of which command touched which resource. The root cause is the lack of just-in-time access, which forces every request to run with the same elevated privileges.
Just-in-time access: the missing piece
What you really need is a way to issue permissions only at the moment they are required, and to retire them as soon as the operation finishes. This approach limits blast radius, forces a conscious decision before each privileged action, and creates a natural audit point. However, simply deciding to use just-in-time access does not solve the core engineering gap: the request still travels directly to the Kubernetes API server, bypassing any enforcement layer, and no session is recorded or masked.
hoop.dev as the identity‑aware gateway
hoop.dev sits on the network edge and becomes the only path through which MCP servers reach the EKS control plane. Because hoop.dev is the data path, it can enforce just-in-time access, require an approval workflow, and record every kubectl or exec command. hoop.dev masks sensitive fields in API responses, blocks dangerous operations before they reach the cluster, and stores a replayable session log for later review. In this model, the enforcement outcomes exist solely because hoop.dev occupies the gateway position.
How the architecture works for MCP servers
When an MCP server initiates a connection, it authenticates to hoop.dev using an OIDC token. hoop.dev validates the token, extracts group membership, and determines whether the request matches a just-in-time access policy. If approval is required, the request is queued until a human reviewer grants it. Once approved, hoop.dev’s agent assumes a dedicated IAM role that has been pre‑configured for EKS authentication. That role is mapped to a Kubernetes RBAC binding, so the server’s session inherits the exact permissions needed for the operation. Throughout the session, hoop.dev records each command, applies inline masking to any response that contains secrets, and can terminate the connection if a policy violation is detected.
The approval workflow can be configured to require multi‑person sign‑off for high‑risk namespaces, while low‑risk operations may be auto‑approved after a short delay. Because hoop.dev sits in the data path, every command, whether a simple pod list or a privileged exec, passes through the same guardrails. The gateway also enriches each audit entry with the identity that performed the action, the time, and the exact API call, giving operators a complete forensic picture.