Configuring MCP servers access to EKS with non-human identity

How can an MCP server authenticate to an EKS cluster without a human‑held credential? In modern pipelines, automated services, AI assistants, and CI/CD jobs need to talk to Kubernetes, but the traditional approach still relies on static kubeconfig files or long‑lived service‑account tokens. Those artifacts are often copied across teams, stored in Git, and never expire. The result is a moving target for credential leakage, no visibility into which automation performed which kubectl command, and no way to hide sensitive data that appears in API responses.

Using a non-human identity, for example an OIDC‑issued token or an AWS IAM role, addresses the first problem: the secret never lives in a developer’s laptop. The token can be short‑lived, scoped to a single request, and revoked centrally. However, even when the token is verified by the EKS control plane, the request still travels directly from the service to the cluster. That direct path means the organization loses three critical controls:

• There is no gate that can inspect each kubectl or exec command before it reaches the API server.
• Responses that contain secrets, passwords, or tokens flow back unfiltered to the caller.
• Every interaction is invisible to auditors because no central log captures the command‑level activity.

Those gaps remain open until a dedicated data‑path component sits between the caller and the cluster. That component must be able to verify the non-human identity, enforce policies, mask data, and record the entire session.

Why the data path must host enforcement for non‑human identity

When an MCP server presents an OIDC token, the token proves who the caller is, but it does not enforce what the caller may do. The enforcement point therefore has to be the gateway that actually carries the traffic. By placing a Layer 7 proxy in front of the EKS API, the organization gains a single place to apply:

• Just‑in‑time (JIT) access: the proxy can grant a temporary RBAC binding that expires as soon as the session ends.
• Inline data masking: any field that matches a sensitive pattern (for example, password or token) is replaced before it reaches the caller.
• Command‑level audit: every kubectl invocation, exec session, and API request is logged with the identity that issued it.
• Guardrails: risky operations such as delete namespace can be blocked or routed to a human approver.

All of those outcomes are possible only because the proxy sits in the data path. The upstream identity system (OIDC, AWS IAM) merely tells the proxy who is asking; the proxy decides what to allow.

How hoop.dev implements the gateway for EKS

hoop.dev provides the required Layer 7 gateway. Its architecture for an EKS connection follows a clear chain:

1. Identity verification: The gateway receives an OIDC token from the MCP server and validates it against the configured IdP. Group membership and claims are extracted to drive policy decisions.
2. Credential handling: The gateway agent, running inside the same network as the EKS cluster, assumes a dedicated IAM role that has permission to call EKS describe operations and to generate a Kubernetes token. This role is the EKS_ROLE_ARN configured on the connection.
3. RBAC mapping: The assumed role is mapped to a Kubernetes ClusterRoleBinding. When a session starts, the gateway creates a short‑lived binding that ties the session name to a specific Kubernetes role, ensuring the access is JIT and revocable.
4. Policy enforcement: As traffic flows through the gateway, hoop.dev inspects each request at the protocol level. It can block disallowed verbs, require human approval for destructive actions, and apply inline masking to response fields that match configured patterns.
5. Session recording: Every request and response, along with the originating identity, is stored in an audit log. The recordings can be replayed later for forensics or compliance reviews.

Because the gateway holds the cluster credential, the MCP server never sees a secret. The server only presents its OIDC token, and hoop.dev does the heavy lifting of assuming the IAM role, generating the Kubernetes token, and enforcing policy.

Benefits of routing MCP traffic through hoop.dev

When an organization adopts this pattern, it gains concrete security and operational advantages:

• Zero‑exposure credentials: Service accounts and AI agents never store kubeconfig files; the only secret lives inside the gateway.
• Full visibility: Auditors can query the session logs to see exactly which automated job ran kubectl apply on which namespace and when.
• Risk reduction: Dangerous commands are intercepted before they can affect the cluster, and any attempt to read secret data is automatically redacted.
• Compliance support: The recorded evidence satisfies requirements for standards that demand traceability of privileged actions.

All these outcomes are possible only because hoop.dev sits in the data path between the MCP server and the EKS control plane.

Getting started

To try this flow, start with the official getting‑started guide. It walks you through deploying the gateway, configuring an OIDC provider, and creating the IAM role that the agent will assume. The learn section contains deeper explanations of masking policies, JIT bindings, and session replay.

All configuration files and example manifests are available in the open‑source repository. Clone the repo at github.com/hoophq/hoop and follow the README for the EKS quick‑start.

FAQ

Q: Does this approach require changes to my existing CI pipelines?
A: No. The pipeline continues to invoke kubectl or the Kubernetes client library. The only change is that the command is routed through the hoop.dev CLI or proxy endpoint, which injects the short‑lived token automatically.

Q: Can I still use my existing service‑account tokens for other tools?
A: Yes. hoop.dev only intercepts traffic that is explicitly directed at its gateway. Other tools can continue to use their own credentials, but they will not benefit from the masking and audit features.

Q: How long are the JIT RBAC bindings kept?
A: Bindings are created when a session starts and are automatically removed when the session ends, ensuring the privilege window is as short as possible.

By routing MCP server traffic through hoop.dev, you turn a static, opaque credential model into a controlled, observable, and revocable access pattern that works natively with EKS.