Kubernetes MCP server: setup, auth, production

What is the Kubernetes MCP server?

A Kubernetes MCP server implements the Model Context Protocol and exposes Kubernetes's capabilities as typed tools an agent can discover and call in the middle of a task. Servers here are community-maintained, which makes provenance and pinning part of the setup rather than an afterthought. What this setup has in common with every other integration in the Infra & cloud category is covered under Infra & cloud on the MCP index.

A real Kubernetes workflow

A pod is crash-looping. The agent reads the deployment, recent events, and logs, identifies the failed readiness probe or the missing config, and drafts the manifest change — diagnosis at the speed of kubectl, without the write access.

What an agent can do with Kubernetes

• Let an agent inspect pod, deployment, and event state
• Investigate a crash-looping service
• Draft a manifest change for review

Read-only is the right default: let the agent observe and reason first, then grant specific write actions deliberately — each behind audit logging and, for anything high-impact, human approval.

Setting up the Kubernetes MCP server

Bind a service account to a read-mostly ClusterRole (get/list/watch), namespaced where possible. Keep it out of secrets unless a workflow needs them, and never grant it apply/delete on production.

Auth: A scoped service account with read-mostly RBAC. Credentials belong in the environment or a secret store — never in the repo or the agent's sandbox. Wiring a server into Claude Code or Cursor is the same for every tool; the step-by-step lives in the MCP connection guide.

The risk to watch with Kubernetes

An agent with write RBAC on a production cluster can delete a Deployment as easily as read one. Read-mostly RBAC, no standing write to prod, and secrets access only where justified.

Scoping a Kubernetes server down

Use RBAC properly here: a service account bound to a role that grants get, list and watch on the specific resource types in the specific namespaces the agent should see. Reading pod logs is usually the point of the exercise and is also where sensitive data leaks, since applications log more than their authors intended. Exclude secrets from the role entirely — an agent that can read secrets in a namespace can read every credential your workloads use. Exec into pods, deletions and scaling are writes that should require a human, because the difference between a helpful restart and an outage is context the agent does not have.

More broadly, a production-grade Kubernetes integration needs rBAC scoping and preventing accidental writes to production clusters. The MCP security checklist applies to every integration — we build servers with these controls baked in.