How can you enable just-in-time access for an MCP server on EKS without handing out long‑lived credentials?
Most teams today solve the problem by creating a shared service account or embedding a static AWS IAM key in deployment pipelines. The credential lives on disk, in CI variables, and often in the hands of several engineers. When a new engineer joins, the same secret is handed over; when the engineer leaves, the key is rotated only after a painful manual process. The result is broad standing access, no visibility into who ran which command, and a high risk that a compromised secret can be used to pivot across the entire cluster.
Just-in-time access promises to replace static secrets with short‑lived, request‑driven permissions. An engineer asks for access, a policy checks the request, and a token is minted for the duration of the task. The idea reduces blast radius and enforces the principle of least privilege. However, if the request still reaches the EKS API directly, the system lacks a central point to enforce masking, command‑level approval, or session recording. The request bypasses any guardrails that could prevent a dangerous kubectl exec or a rogue API call.
This is where an identity‑aware gateway becomes essential. By inserting a Layer 7 proxy between the requester and the Kubernetes control plane, you gain a choke point that can inspect every API call, enforce just-in-time policies, and capture a complete audit trail. The gateway holds the credential that talks to the cluster, so users never see it. It also provides a place to apply inline data masking for sensitive fields returned by the API.
Why just-in-time access matters for MCP servers on EKS
MCP (Model‑Control‑Plane) servers often expose internal configuration endpoints, secret management APIs, or debugging interfaces. A single unchecked request can leak credentials, alter deployment manifests, or trigger a cascade of pod restarts. When developers use long‑lived IAM roles, the risk multiplies because the same role can be reused across environments and projects. Just-in-time access limits the window of exposure to the exact minutes a task needs, and it ties that window to a concrete approval workflow.
Beyond the time‑bound aspect, you also need visibility. Auditors ask for evidence that a specific engineer executed a particular kubectl command, what the input parameters were, and whether any sensitive fields were returned. Without a central data path, that evidence is scattered across client logs, kube‑audit logs, and possibly missing entirely if a user disables logging.
Architectural pattern with an identity‑aware gateway
The pattern starts with a strong identity foundation. Engineers authenticate to an OIDC provider (Okta, Azure AD, Google Workspace, etc.). The provider issues a token that includes group membership. The gateway validates the token and maps the groups to a set of policies that define which EKS clusters, namespaces, or resources a user may access and for how long.
On the infrastructure side, the gateway runs an agent inside the same VPC as the EKS cluster. The agent assumes a dedicated IAM role that the gateway has been configured to use for EKS authentication. That role is distinct from any user‑owned role and is only ever used by the agent. The role is mapped to a Kubernetes RBAC binding, so when the gateway presents its service account to the API server, the API server treats it as a specific Kubernetes user.
When a developer initiates a connection, using the standard kubectl client or an HTTP client against the MCP endpoint, the request first hits the gateway. The gateway checks the request against the just-in-time policy, optionally routes it through an approval workflow, and then forwards it to the EKS API server. Because the gateway sits in the data path, it can mask fields like secret values in API responses, block dangerous verbs such as delete on a production namespace without explicit approval, and record the entire session for later replay.
How hoop.dev enforces the controls
Setup. You provision the gateway with OIDC authentication and configure a connection that points at the target EKS cluster. The connection includes the ARN of the IAM role the agent will assume. This step decides who may start a request and what initial scope they have, but it does not enforce any runtime guardrails.
The data path. hoop.dev sits directly in front of the Kubernetes API. Every API call, whether it is a kubectl get pods or an HTTP request to an MCP health endpoint, passes through the gateway. Because the gateway is the only place the traffic is inspected, it is the sole location where enforcement can happen.
Enforcement outcomes. hoop.dev records each session, preserving the full command stream and API payloads. It masks sensitive fields in responses according to policy, ensuring that even privileged users never see raw secret values unless explicitly allowed. When a request matches a high‑risk pattern, hoop.dev blocks the command or routes it to a human approver before forwarding it. All of these outcomes exist only because hoop.dev occupies the data path.
The result is a complete, auditable workflow: a developer requests just-in-time access, the request is evaluated, the gateway forwards the request with a short‑lived credential, and every interaction is captured and masked as needed. The engineer never sees the underlying IAM key, and the organization gains the evidence required for security reviews.
Getting started
To try this pattern, start with the official getting‑started guide, which walks you through deploying the gateway, configuring OIDC, and creating an EKS connection. The documentation also explains how to define just-in-time policies and enable session recording. For a deeper dive into feature capabilities, see the learn section.
FAQ
- Do I need to change my existing kubectl workflow? No. The gateway accepts standard kubectl commands, so developers continue to use familiar tools. The only change is the endpoint they point at, which is the gateway address.
- What happens if the gateway is unavailable? Because the gateway holds the credential, a failure isolates access rather than exposing the IAM role. You can configure high‑availability deployments to minimize disruption.
- Can I still use role‑based access control inside Kubernetes? Yes. The gateway maps the assumed IAM role to a Kubernetes RBAC binding, so existing RBAC policies continue to apply on top of the just-in-time layer.
Ready to add just-in-time access with full audit and masking for your MCP servers on EKS? Explore the open‑source repository and follow the getting‑started documentation to deploy the gateway in your environment.
