Kubernetes-MCP-Guard

by mirusser

Not rated
GitHub

About

AI-safe approval plan gated Kubernetes operations through MCP with OAuth, RBAC, audit, guardrails.

Details

Author
mirusser
Categories
Developer Tools, Security

Setup

Install Kubernetes-MCP-Guard in your MCP client (Claude Desktop, Cursor, Windsurf, and others).

Repository: https://github.com/mirusser/Kubernetes-MCP-Guard

Follow the installation instructions in the repository README, then restart your MCP client.

AI-safe approval plan gated Kubernetes operations through MCP with OAuth, RBAC, audit, guardrails.

Human-approved, AI-driven Kubernetes remediation through a guarded MCP gateway.

Observer detects anomalies.
Planner proposes an evidence-backed plan.
Human reviewer approves out-of-band.
Executor runs only the approved digest-bound plan.
Everything is auditable.

When something breaks, the system can collect evidence, propose a bounded fix, dry-run it, package it into a reviewable plan, and wait for a human to approve.

It is a security-first bridge between AI agents and Kubernetes, with out-of-band, OAuth-authenticated, human-in-the-loop (HITL), plan-based approval for every gateway-exposed mutation.

AI agents can help diagnose infrastructure problems, but giving them direct mutation access is risky. Kubernetes MCP Guard explores a safer pattern: agents may observe, dry-run, and propose bounded remediations, while humans approve the exact digest-bound plan before any Kubernetes write occurs.

https://github.com/user-attachments/assets/4e06b4ee-db80-4d74-96cc-38dfbb413042
- A Deployment is intentionally broken.
- The Observer detects the unhealthy workload.
- The Planner proposes a bounded remediation.
- An approval access code is sent to the configured operator by email.
- An authenticated human approves the exact plan in the browser.
- The Executor applies the approved mutation.

The walkthrough indocs/demo-failing-deployment.mdshows the full flow against a deliberately broken Deployment.

Kubernetes MCP Guard explores a practical safety pattern for AI-assisted operations:

- Plan before mutate:every gateway-exposed write starts as arequest_plan built from Kubernetes server-side dry-run evidence.
- Separate review channel:the MCP client receives an approval URL, while approval happens through/approvals/
in a browser OAuth session.
- Digest-bound approval:execution is bound to an Intent Digest for the executable mutation and a Review Digest for the human-reviewed snapshot.
- Durable grant model:an approved Approval Challenge records a Challenge Outcome and issues an Approval Grant consumed by pre-execution gates.
- Narrow Kubernetes scope:namespace allow-lists, namespace-scoped RBAC, supported-kind checks, and bounded read tools keep the operational surface small.
- Auditable controls:guardrail and approval events are written as JSONL streams with identity, digest, grant, and execution context.
- Structured multi-agent coordination:Observer, Planner, and Executor are independent processes (agents) that communicate over the
A2A protocol(viaa2a-dotnet), each with a separate OAuth service identity and a narrow gateway scope. The Planner owns a durable per-anomaly Task that persists across restarts and enforces one-remediation-per-anomaly without cross-service locking.

The repository also separates the generic approval lifecycle from the Kubernetes adapter, so the core language is not tied to one infrastructure domain.

SeeCONTEXT.md,docs/mutation-approval-profile.md,docs/mutation-approval-flow.md.

--- title: Security Boundaries --- flowchart TB subgraph outer["🌐 Internet / Operator"] Human["πŸ‘€ Operator\nbrowser Β· OAuth PKCE"] McpClient["πŸ€– MCP Client\nCodex Β· Claude Code"] end subgraph gateway["πŸ›‘οΈ Gateway β€” OAuth JWT required"] direction LR Guard["πŸ” Guardrails\n+ ToolScopeGuard"] ApprovalUI["πŸ“‹ Approval UI\n/approvals/"] ApprovalCore["πŸ” Approval Core\nplan Β· challenge Β· grant Β· digest"] end subgraph agents["πŸ€– Agent Tier β€” client_credentials Β· narrow scopes"] direction LR Obs["πŸ”Ž Observer\nmcp:tools.readonly"] Plan["πŸ“‹ Planner\nmcp:tools.propose + readonly"] Exec["πŸ› οΈ Executor\nmcp:tools.execute"] Obs <-->|"A2A"| Plan <-->|"A2A"| Exec end subgraph private["πŸ”’ Private Subprocess β€” no public port"] McpServer["βš™οΈ McpServer\nKubernetes tools"] end K8s(("☸️ Kubernetes API\n(namespace-scoped RBAC)")) Human -->|"review snapshot Β· approve/deny"| ApprovalUI --> ApprovalCore McpClient -->|"Bearer JWT Β· mcp:tools.read/write"| Guard -->|"scope-filtered tool call"| ApprovalCore agents -->|"Bearer JWT Β· service identity"| Guard ApprovalCore -->|"stdio Β· service token"| McpServer -->|"KubernetesClient"| K8s

The Observer notifies the Planner and the Planner dispatches to the Executor synchronously and waits for the outcome.

The Planner's internal remediation pipeline is a concurrent DAG built onMicrosoft.Agents.AI.Workflows, fanning each incoming anomaly through independent:Filter β†’ Dedupe β†’ LLM-Decide β†’ Validate β†’ Propose executor chains.

Full request-flow diagrams live indocs/architecture.md.

The central safety property is that approval is necessary but not sufficient. A human approval creates execution authorization, but execution still has to pass the pre-execution gates immediately before Kubernetes is mutated.

Current implementation notes are tracked indocs/mutation-approval-profile.md#current-repository-fit.

TheInfraGate.Observeris an LLM-driven agent that periodically inspects the cluster through the gateway's read-only tools and emits structured Anomaly Reports.

TheInfraGate.Plannerconsumes Anomaly Reports, chooses a bounded remediation operation, and creates approval-pending Operator Approval Policy plans throughpropose_plan.

TheInfraGate.Executorconsumes Planner proposals, waits for approval, and executes only after the gateway reports that an Approval Grant exists.

Direct Kubernetes mutation tools exist inside the private server surface for the adapter executor. The HTTP gateway exposesrequest_wrappers plusexecute_approved_planinstead of exposing raw destructive tools to MCP clients.

Prerequisites:Docker Compose v2,kubectl,minikube, andgit.

Reviewdocs/configuration.mdbefore changing runtime settings.

The default quickstart uses published images and committed local-demo defaults.

git clone https://github.com/mirusser/Kubernetes-MCP-Guard.git cd Kubernetes-MCP-Guard export InfraGate__OpenRouter__ApiKey="<openrouter-api-key>" make quickstart

make quickstartstarts the local Keycloak-backed OAuth path, PostgreSQL approval store, and published gateway image withTAG=latest. Pin a release withTAG=v0.1.0 make quickstart. The committed no-SDK defaults come from thesmoke-releaseRun Profile:deploy/local-oauth/release.env.examplesupplies both Compose interpolation andInfraGate__...runtime settings.

Use source mode when you want the gateway, Observer, Planner, and Executor built from local code. This path also requires the[.NET 10 SDKand an OpenRouter API key for the LLM-backed agents.

export InfraGate__OpenRouter__ApiKey="<openrouter-api-key>" make quickstart-source

…

No reviews yet β€” be the first

Sign in to leave a review

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.