Many assume that attaching an OIDC identity to an MCP server automatically secures its access to an EKS cluster, but oidc/sso alone does not provide runtime enforcement. In reality the server still talks directly to the Kubernetes API using a static IAM role, bypassing any runtime checks. The result is a hidden attack surface that looks clean on paper but offers no guardrails once the connection is established.
Typical deployments give an MCP server a long‑lived AWS IAM role that can list, create, or delete pods. Engineers share that role across many services, and the role is stored in configuration files or environment variables. Because the credential never changes, any compromised service instantly inherits full cluster privileges. No audit trail records which command was run, and no one can retroactively verify whether a destructive operation was intentional.
Introducing OIDC/SSO changes the way the MCP server authenticates, but it does not change the data path. The server still forwards API calls straight to the EKS endpoint after the OIDC token is exchanged for a static role. The request reaches the Kubernetes control plane without passing through any point that can inspect, mask, or block the payload. Consequently the organization gains identity federation but retains unrestricted, unrecorded access.
Why oidc/sso alone isn’t enough
OIDC/SSO provides a trustworthy identity source. It tells the cluster who is making a request, but it does not enforce policy at the moment of execution. Without a gateway, the cluster sees only the final AWS role that the MCP server assumed. There is no place to enforce just‑in‑time permissions, require an approval workflow, or capture a command‑level audit. The missing enforcement layer means that compliance teams cannot prove who ran which kubectl command, and security teams cannot stop a dangerous "kubectl delete" before it hits the API.
hoop.dev as the identity‑aware gateway
hoop.dev inserts a Layer 7 gateway between the MCP server and the EKS control plane. The gateway runs an agent inside the same network as the cluster and assumes the dedicated IAM role configured for EKS access. When an MCP server presents an OIDC token, hoop.dev validates the token, maps the identity to a Kubernetes RBAC binding, and then forwards the request through the agent.
Because the gateway is the only point where traffic passes, hoop.dev can apply several enforcement outcomes:
- It records each kubectl or exec session, storing a replayable log that shows every command and response.
- It masks sensitive fields in API responses, such as secret data in ConfigMaps, before they reach the client.
- It blocks commands that match a deny list, preventing destructive actions like "kubectl delete namespace" unless an explicit approval is granted.
- It routes high‑risk operations to a human approver, integrating with existing ticketing or chat systems.
- It scopes access to the exact namespace or resource the identity is allowed to touch, enforcing least‑privilege at runtime.
All of these controls happen in the data path, meaning they remain effective even if the MCP server is compromised. The gateway’s policy engine runs outside the server process, so an attacker cannot tamper with the guardrails after gaining a foothold.
Getting started with hoop.dev for EKS
To adopt this model, begin with the official getting‑started guide. Deploy the hoop.dev gateway using Docker Compose or Kubernetes, and configure the EKS connection with the IAM role that the agent will assume. Register the OIDC provider that issues tokens for your MCP servers, and map groups to Kubernetes RBAC roles in the connection definition. The documentation walks through the required IAM role, the role‑assume relationship, and the cluster binding that links a session name to a ClusterRoleBinding.
For an overview of what hoop.dev can do, see the product page. Once the gateway is running, any MCP server that presents a valid OIDC token will be forced through hoop.dev. From that point onward, every command is recorded, every response can be masked, and any risky operation can be paused for approval.
For the full source code, contribution guidelines, and issue tracker, visit the GitHub repository. The project is MIT licensed and welcomes community contributions.
FAQ
- Do I still need IAM policies on the EKS cluster? Yes. The IAM role that the hoop.dev agent assumes must have permission to call the Kubernetes API. hoop.dev then adds a second layer of enforcement based on the presented OIDC identity.
- Can I use existing OIDC providers such as Okta or Azure AD? Absolutely. hoop.dev works with any OIDC‑compatible identity provider. The provider issues the token; hoop.dev validates it and extracts group claims for policy decisions.
- What happens to logs after a session ends? hoop.dev stores a replayable session record that can be queried later for audit or forensic analysis. The logs are retained according to the retention policy you configure in the gateway.
