
Kubeleash
io.github.kubeleashPublished by GitHub account kubeleashv0.3.0Updated Oct 24, 2026
Kubernetes MCP server with RBAC-style, context-scoped guardrails for AI agents.
Overview
A local MCP server for Kubernetes that lets an AI assistant list, read, apply, delete, scale and exec against cluster resources, gated by a context-scoped local
- What you can do
- List and read any Kubernetes resource, including CRDs, with generic GVK-agnostic tools (k8s_list, k8s_get). Inspect pod and workload logs (k8s_logs). Create or update resources (k8s_apply), delete them (k8s_delete), and change replica counts (k8s_scale). Run commands in containers (k8s_exec). Query what the current policy and context allow (k8s_capabilities). Every call is checked against a local policy file and written to a JSON audit log on stderr.
- When to use it
- When you want an AI assistant to work with a real Kubernetes cluster but only within limits you define per kube context, for example read-only in production and broader in staging or dev. Useful when the kubeconfig is more privileged than you want the agent to be.
- Requirements
- Runs locally over stdio; the client launches the binary. Install via Homebrew, go install, the container image, or the Claude Desktop bundle. A policy file is required via the --policy flag or the K8S_MCP_POLICY variable, otherwise it refuses to start. A kubeconfig is used from --kubeconfig, KUBECONFIG or the default location, and network access to the cluster API server is needed.
Installation
In SourceWeft
- Open Kubeleash in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
[CI] [Go Report Card] [OpenSSF Scorecard] [License] [Release]
Guardrails for AI agents on your cluster. kubeleash is a local MCP server for Kubernetes whose differentiator is RBAC-style, context-scoped access control. Point it at a kubeconfig — even a cluster-admin one — and a local policy file constrains what the agent can actually do, per kube context, with destructive actions gated before any call reaches the cluster.
Add kubeleash to your AI client
[Add to VS Code] [Add to Cursor] [Claude Code / Desktop]
Install launches the local kubeleash binary — get it via brew, go install, or the container (see Install). VS Code installs in one click; Cursor & Claude open the setup steps (GitHub strips the cursor:// one-click link, so it lives there as copy-paste).
Why
Most Kubernetes MCP servers inherit the kubeconfig's permissions wholesale — whatever the credentials grant, the agent can do. kubeleash adds three things native RBAC can't express for this use case:
- Constrain the agent independently of the credentials. Effective access is
always
kubeconfig-grants ∩ policy-allows— kubeleash only ever subtracts. - Context-aware guardrails. Policy varies by context (prod vs staging vs dev); native RBAC is per-cluster.
- Block destructive verbs (
delete/exec/…) as a safety net against agent mistakes and prompt injection.
What kubeleash enforces
kubeleash governs only the calls routed through it. It provides a hard
guarantee when it is the agent's sole path to the cluster. An agent that also
has shell access (raw kubectl, oc, the API) can step around it, so in a
shell-enabled assistant kubeleash is advisory — pair it with the
using-kubeleash skill, which instructs the agent to stop (not reach for
kubectl) when the leash is unavailable.
Policy in 10 seconds
Deny wins. Default deny. A broken policy refuses to start — it never fails open.
See examples/policy.yaml for a fuller, commented policy
(read-only prod, broader staging, namespace-scoped dev).
Quickstart
Install it (Homebrew shown — see Install for go install and the
container), then exercise a policy without touching any cluster:
Prefer source? git clone https://github.com/kubeleash/kubeleash && cd kubeleash && go build -o kubeleash ./cmd/kubeleash (Go 1.26+).
Then point an MCP client at it (see below). kubeleash speaks MCP over stdio, so it's launched by your client, not run as a daemon.
Install
All channels run kubeleash locally over stdio — your client launches the
binary; nothing is hosted. kubeleash is listed in the
official MCP Registry as
io.github.kubeleash/kubeleash, so registry-aware clients can discover it too.
One-click
The Add to Cursor / VS Code buttons
at the top are the fastest path (they need
the kubeleash binary on PATH — see Manual). Other clients:
Claude Code — this repo is its own plugin marketplace:
No separate install step: on first run the plugin uses a kubeleash already on
your PATH, or otherwise downloads the matching release binary (verifying its
checksum) and caches it.
Safe by default — no policy authoring required first: if you have no policy at
~/.kubeleash/policy.yaml, the plugin writes a read-only starter there on
first run (allow get/list/watch, deny exec/delete). Review and widen
it to grant more access. (This convenience is the plugin's only; the raw binary
still requires an explicit --policy and refuses to start without one.)
The plugin also ships two skills — using-kubeleash (how an agent should query
and act through the gated tools) and authoring-kubeleash-policy (how to write
the policy) — so the agent understands the guardrails, not just the tool list.
Claude Desktop — download kubeleash.mcpb from the
releases page and
double-click it; the bundle ships the binary and prompts you for the policy and
kubeconfig.
Raw Cursor / VS Code deeplink URLs (if a button doesn't fire)
Cursor (can't prompt — edit the placeholder path afterward in Settings → MCP).
Decodes to {"command":"kubeleash","args":["--policy","/absolute/path/to/policy.yaml"]}:
VS Code (prompts for the policy path):
Manual
kubeleash runs locally over stdio and talks only to your clusters. There is intentionally no remote/hosted URL connector — it would mean handing your cluster credentials to a third party.
Use it as an MCP server
kubeleash exposes 8 generic, GVK-agnostic tools (k8s_list, k8s_get,
k8s_apply, k8s_delete, k8s_logs, k8s_exec, k8s_scale, and
k8s_capabilities) that work for any resource, including CRDs. Every call is
checked against your policy and recorded to a JSON audit log on stderr (stdout
is the MCP transport). It speaks MCP over stdio — point your client at the
binary (or container):
Privacy
Zero telemetry. No phone-home. Local-only by design. kubeleash talks only to the Kubernetes API servers you point it at — there is intentionally no remote or hosted connector to route your cluster credentials through. That's a feature, not a gap: you run it against real clusters with privileged credentials, so nothing should sit between the agent and your API server but the leash.
Project
- Design · Contributing · Security & threat model · Code of Conduct
- License: Apache-2.0
Source: README.md at commit f0cdb09
Tools
0Version history
1- v0.3.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts