Kubernetes MCP servers compared: auth, limits, approval

An MCP server for Kubernetes is the piece that turns an agent's tool call (list pods, get logs, apply this YAML) into a request to the cluster's API. The tools look alike from project to project. What differs is the identity the request is made with, and what, besides that identity's RBAC, can say no.

The short answer

Trying it on your own machine: containers/kubernetes-mcp-server runs with npx or uvx against your kubeconfig, works with Claude, Cursor and VS Code, and has a read-only mode. Point it at a read-only ServiceAccount, not your admin context (below).
Clusters on EKS or AKS: the AWS and Azure servers use your cloud identity and start read-only by default.
A team giving agents shared, limited access: a remote server with one credential per client, scoped to named clusters, expiring and logged. That is what Subnomic’s MCP is; it needs the Subnomic agent in the cluster and the Team plan.

The four at a glance

	Runs	Credentials	Read-only switch	Approval before a change
containers/kubernetes-mcp-server (Red Hat)	Locally over stdio; Streamable HTTP when a port is set	The kubeconfig, or the pod's in-cluster config	`read_only = true`, plus `denied_resources` and toolsets	`confirmation_rules` ask through MCP elicitation; if the client cannot ask, the default fallback is allow
Flux159/mcp-server-kubernetes	Locally over stdio; HTTP behind `ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT`	`~/.kube/config`, or a kubeconfig or server token in the environment	`ALLOW_ONLY_READONLY_TOOLS`, `ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS`, `ALLOWED_TOOLS`	None documented
awslabs eks-mcp-server	Locally over stdio (`uvx`)	AWS credentials from the environment, with an EKS access entry; or a kubeconfig	Read-only by default; `--allow-write` and `--allow-sensitive-data-access` open more	None in the server
Azure/aks-mcp	Locally over stdio only	An Azure CLI identity: `az login`, a service principal, workload or managed identity	`--access-level` readonly (default), readwrite or admin	None documented

AWS also runs a hosted Amazon EKS MCP Server, in preview: requests are signed with SigV4 through mcp-proxy-for-aws, IAM has separate actions for read-only and privileged tools, and CloudTrail records the calls.

The agent is whoever the server runs as

Every self-hosted server above acts with one identity: the kubeconfig on the machine that starts it, or the Azure or AWS login it inherits. Their own documentation says the same thing about their switches. The Red Hat server calls read_only and denied_resources “best-effort guardrails” and points to RBAC on its identity as the control to rely on; AKS-MCP says its access level is “not a security boundary” and that anyone who can call its tools has the full privileges of the identity it runs under.

So the practical setup is the same for all of them: create a ServiceAccount or IAM role for the agent alone, give it the narrowest RBAC that does the job, and point the server at that, not at your own admin kubeconfig.

What each one records

Red Hat: optional OpenTelemetry traces and metrics; no audit log of its own.
Flux159: OpenTelemetry tracing, and secrets masked in kubectl get secrets output.
EKS (open source): the README recommends CloudTrail for the AWS API calls it makes.
EKS (hosted, preview): CloudTrail captures tool calls.
AKS-MCP: no audit log or per-caller authorization documented.

The Kubernetes API server's own audit log sees every request too, attributed to the identity the server used, which is why a dedicated ServiceAccount per agent makes that log readable.

Local stdio or a remote server

Over stdio, the MCP server is a process on the developer's machine and uses that machine's credentials; the MCP specification says stdio servers should take credentials from the environment. A remote server over HTTP is a shared endpoint, and the specification's authorization chapter describes it as an OAuth 2.1 resource server that must not pass the client's token through to the API behind it. Of the four, only the Red Hat server documents OAuth for its HTTP mode; Flux159's HTTP mode takes a shared header token, and AKS-MCP refuses to be exposed over HTTP at all.

Running one yourself, read-only

The Red Hat server starts with one command, and its README shows the client configuration:

npx -y kubernetes-mcp-server@latest --help
uvx kubernetes-mcp-server@latest --help

# VS Code
code --add-mcp '{"name":"kubernetes","command":"npx","args":["kubernetes-mcp-server@latest"]}'

Its read-only switch is read_only = true in its TOML configuration; settings are no longer command-line flags. Whichever server you run, give it an identity of its own. Kubernetes ships a view ClusterRole that reads most objects and not Secrets:

kubectl create namespace mcp
kubectl create serviceaccount mcp-reader -n mcp
kubectl create clusterrolebinding mcp-reader-view \
  --clusterrole=view --serviceaccount=mcp:mcp-reader
kubectl create token mcp-reader -n mcp --duration=8h

Put that token in a kubeconfig of its own and start the server with KUBECONFIG pointing at it. The agent then reads what view allows, and the token runs out on its own.

Where Subnomic fits

Subnomic runs a remote MCP server at app.subnomic.com/mcp. It reaches clusters through the Subnomic agent already running in them, so the agent's laptop holds no kubeconfig and the cluster opens no port. What changes compared with the servers above:

The credential names its limits. One token per MCP client, with the capabilities you tick (read a cluster, change workloads, delete, run SQL…), the clusters, hosts and databases it may touch, and an expiry of 7 to 360 days. It never exceeds what the person who minted it can do.
Guardrails are checked before the call. Rules match the change itself, for example ^kubernetes\.delete\b.*\bns=prod\b. A rule that requires approval refuses an MCP call, because nobody is there to ask; an agent can request just-in-time access but never approve it.
Calls are recorded per credential. Each credential keeps its last 300 calls with tool, outcome and duration, and changes land in the workspace activity log attributed to the agent.

What it does not do, so you can weigh it fairly: it is a hosted service, not something you run yourself; it authenticates with a bearer credential you mint in the console, not OAuth; it speaks Streamable HTTP only, so a client limited to the older SSE transport cannot connect; and it needs the Subnomic agent in the cluster. MCP for your own clients is part of Team and Enterprise.

The tool list and capabilities are on the MCP page; setting up a client is in Connect Claude Code or Cursor to Kubernetes; a worked example is Investigate a Kubernetes incident with an AI agent.

Sources

What this page says about other products is taken from their own pages, read on 12 November 2026. Plans and limits change; if one of these has, tell us and we will correct it.

Kubernetes MCP servers: how each one reaches the cluster, and what stops the agent