How can you let an automated service talk to a Kubernetes cluster without exposing human credentials, while still using a non-human identity that limits blast radius?
Why the current approach falls short
Most teams that run MCP (Model‑Control‑Plane) servers on Kubernetes simply copy a kubeconfig file into the container, or mount a long‑lived service‑account token. The token is often generated once, stored in a secret, and then reused for weeks or months. This practice gives the service a static identity that never changes, making revocation painful and audit noisy. If the secret leaks, an attacker gains the same level of cluster access as a human operator.
Because the service connects directly to the API server, the request bypasses any runtime guardrails. The cluster sees a valid bearer token and honors it, but there is no record of which command triggered a change, no inline redaction of sensitive fields, and no opportunity to require a human approval before a destructive operation.
What a non-human identity must solve
Introducing a non-human identity means the MCP server authenticates with a short‑lived, purpose‑bound token instead of a static secret. The token is issued only when the server needs to perform a specific task, and it expires shortly after. This limits the blast radius of a compromised credential and aligns the access window with the actual workload.
Even with a fresh token, the request still travels straight to the Kubernetes API. The cluster validates the token, but it does not enforce just‑in‑time approval, command‑level audit, or automatic masking of response data. Those enforcement outcomes remain missing, leaving the organization exposed to accidental data leakage or unauthorized changes.
hoop.dev as the data‑path enforcement point
hoop.dev sits between the MCP server and the Kubernetes API as a Layer 7 gateway. It receives the short‑lived token, validates the identity, and then proxies the request to the cluster. Because the gateway controls the entire session, it can apply the missing controls without changing the server code.
Setup – Identity is still handled by your existing OIDC or SAML provider. You configure a service‑account or machine identity in the provider, grant it the minimal RBAC needed for the MCP workload, and let hoop.dev verify the token on each connection. The gateway never stores long‑term credentials; it only holds the temporary token for the duration of the session.
The data path – All traffic from the MCP server to the Kubernetes control plane flows through hoop.dev. Because the gateway sits on the wire, it can inspect every API call, enforce policies, and record the interaction before it reaches the cluster.
Enforcement outcomes – hoop.dev records each request and response, providing a replayable audit trail. It can mask fields such as secrets or tokens in API responses, ensuring that downstream logs never contain raw credentials. When a command matches a high‑risk pattern, hoop.dev can pause the request and route it to a human approver, implementing just‑in‑time approval. It can also block prohibited operations entirely, preventing accidental deletion of critical namespaces.
Implementing non-human identity for MCP servers
- Define a machine client in your OIDC provider with a short token lifespan.
- Grant that client the minimal Kubernetes RBAC needed for the MCP workload.
- Deploy hoop.dev’s gateway in the same network segment as the Kubernetes API server.
- Register the Kubernetes cluster as a connection in hoop.dev, providing the API endpoint and a bootstrap credential that the gateway will use to speak to the cluster.
- Configure the MCP server to obtain a token from the identity provider at start‑up and to connect through the hoop.dev endpoint instead of directly to the API server.
With this arrangement, the MCP server never sees a long‑lived secret, and every interaction is subject to the gateway’s policies.
Why this matters for security and compliance
By moving the enforcement point to hoop.dev, you gain continuous evidence of who performed which Kubernetes operation and when. This evidence satisfies audit requirements for standards such as SOC 2, because the logs are retained independently of the workload and can be reviewed for compliance. Inline masking ensures that sensitive data never leaves the gateway in clear text, reducing the risk of accidental exposure in downstream monitoring pipelines.
Because the gateway can require just‑in‑time approval, you can enforce the principle of least privilege at the command level, not just at the role level. An automated job that normally only reads resources can be forced to pause before attempting a write, and a human can decide whether the write is appropriate in that context.
Getting started
For a step‑by‑step walkthrough, see the getting‑started guide. The documentation explains how to configure your identity provider, register a Kubernetes connection, and point an MCP server at the hoop.dev endpoint.
Additional details about policy configuration, session replay, and masking rules are available in the learn section of the site.
FAQ
Do I need to change my existing Kubernetes RBAC?
Only to the extent that the machine identity used by the MCP server must have the permissions it truly needs. hoop.dev does not alter RBAC; it enforces additional controls on top of whatever permissions you grant.
Will hoop.dev add latency to my API calls?
Because hoop.dev operates at Layer 7 and runs close to the API server, the added round‑trip time is typically a few milliseconds, which is negligible for most workloads.
Yes. hoop.dev forwards the original request and response after applying policies, so existing observability pipelines continue to see the traffic, now with optional masking applied.
Explore the source and contribute on GitHub.
