How can you enforce production access control for MCP servers running on Amazon EKS without handing engineers permanent cluster credentials?
Many organizations solve the problem by distributing static kubeconfig files or long‑lived IAM roles that grant broad cluster permissions. The approach is simple, but it leaves every production workload exposed to any user who possesses the file. There is no per‑command audit, no way to hide secrets that appear in logs, and no mechanism to stop a risky command before it reaches the API server.
When a breach or a careless mistake occurs, the damage can spread across the entire cluster because the original access grant never expires and never records what was actually run. Production access control therefore requires a guardrail that limits the window of privilege, records every interaction, and can redact sensitive data on the fly.
The missing piece is a control surface that sits between the identity token and the Kubernetes API. It must be able to verify the user, enforce just‑in‑time (JIT) policies, require human approval for high‑risk actions, mask confidential fields in responses, and capture a replayable session log. All of this has to happen without changing existing client tooling.
Production access control with hoop.dev
hoop.dev provides exactly that control surface. It deploys a Layer 7 gateway that intercepts every request destined for the EKS API server. The gateway runs an agent inside the same network as the cluster and assumes a dedicated IAM role that is mapped to a Kubernetes RBAC binding. Because the gateway is the only point where traffic is inspected, hoop.dev can enforce policies before any command reaches the cluster.
When a user authenticates via OIDC, hoop.dev validates the token and extracts group membership. The request then flows through the gateway, where hoop.dev checks the configured production access control policy. If the command is benign, it is forwarded to the API server. If the command touches a protected resource, hoop.dev can pause execution and route the request to an approval workflow. Once approved, the command is sent to the cluster.
During the session hoop.dev records every kubectl or exec call, masks fields such as passwords or tokens that appear in responses, and stores a replayable log. The user never sees the underlying IAM credentials; the gateway handles all credential use on their behalf. This architecture satisfies the three required layers:
- Setup: Identity providers (OIDC/SAML) decide who is making the request and which groups they belong to.
- The data path: hoop.dev’s gateway is the sole place where enforcement logic runs.
- Enforcement outcomes: hoop.dev records the session, masks sensitive data, requires JIT approval, and can block disallowed commands.
High‑level deployment steps
- Deploy the gateway using the provided Docker Compose file or the Kubernetes helm chart. The quick‑start guide walks you through the network‑resident agent installation.
- Register the EKS cluster as a connection in hoop.dev, supplying the cluster endpoint and the IAM role that the agent will assume.
- Configure OIDC authentication so that engineers obtain short‑lived tokens from your identity provider.
- Define production access control policies that specify which commands require approval, which fields to mask, and how long sessions are retained.
- Enable session recording and replay in the feature settings.
All of these actions are described in the official getting‑started guide. The repository at github.com/hoophq/hoop contains the full source and example manifests.
Why this matters for production workloads
By forcing every interaction through hoop.dev, you obtain a clear, authoritative record of each action and its initiator. Masking prevents accidental leakage of secrets in logs or screen recordings. JIT approval ensures that high‑risk operations, such as deleting a namespace or changing RBAC bindings, only happen with explicit oversight. Session replay lets you reconstruct the exact sequence of commands after an incident, which is essential for forensic analysis and compliance reporting.
FAQ
- Does hoop.dev replace my existing IAM roles? No. The gateway assumes a dedicated IAM role for cluster access, but your existing identity provider and group mappings remain the source of authentication.
- Can I still use standard kubectl commands? Yes. From the user’s perspective the workflow is unchanged; hoop.dev sits transparently between the client and the API server.
- Where are the audit logs stored? hoop.dev records each session and stores the logs in the backend you configure, where they can be reviewed for compliance.
Implementing production access control for MCP servers on EKS is now a matter of deploying hoop.dev, defining the right policies, and letting the gateway enforce them. For the full implementation details, follow the learn page and the repository linked above.
