Kubernetes MCP Server (containers)

In the default local mode the server uses whatever credentials are in the operator's kubeconfig, and the model can pick any context in that file per call, so it inherits the operator's full authority across every cluster they can reach. In HTTP mode the default auth mode forwards the client's bearer token straight to the Kubernetes API (token passthrough), and HTTP-mode access control is not otherwise locked down. An opt-in OAuth mode with token exchange gives each request the requesting user's own cluster identity and fails closed when no token is present, which is a genuinely strong design, but it is off by default and only applies to HTTP deployments.

The server owns no approval loop itself, so it is rated on what it gives the host. Read and write operations are separate tools and every tool in every toolset carries read-only and destructive annotations, with pod exec, deletes, scale, and create-or-update all flagged as non-read-only. The server also offers a server-enforced read-only mode and elicitation-based confirmation rules, but both are off by default, there is no dry-run or preview for destructive operations, and when confirmation rules are configured a client without elicitation support is allowed through by default. A wrongly approved delete or full-replace apply is irreversible.

The default tools are general-purpose: pods_exec runs any command array in any pod, pods_run starts any image, and resources_create_or_update applies any manifest of any kind. Inputs are typed JSON schemas, and a central round tripper can enforce a denied-resources list on every Kubernetes API call, but that list is empty by default, is a denylist of resource kinds only, and pod exec can still read data (such as mounted Secrets) whose kind is denied. Toolsets are selectable, but the default set includes write and exec tools.

The server never runs code on its own host, but pods_exec executes model-chosen commands inside whatever existing container the model names, and pods_run or resources_create_or_update can start any image with any pod spec. There is no sandbox the model cannot redefine: the execution target is a production workload carrying its own service-account token, network access, and mounts, and the model can also create a privileged pod with host mounts if the credentials allow it. Nothing in the server constrains this.

Pod logs, exec output, events, and resource contents (annotations, ConfigMaps) are returned as plain text with no provenance or untrusted marker, so anything a workload writes reaches the model on equal footing with real data. The server offers a read-only mode that would drop the state-change leg, but it is opt-in. In the default configuration a hijacked host agent can read Secrets and the raw kubeconfig and exfiltrate them (for example by running a pod that posts them out) and delete or replace resources, all without the server asking anyone.

The server keeps no memory, conversation store, or retrieval index, and it does not load instruction or configuration files from the working directory. Configuration comes only from an explicit --config/--config-dir path or the MCP_CONFIG_PATH environment variable, and credentials from the user's kubeconfig, all user scope. Cluster state the model writes and later reads back is untrusted input, covered in C5.

The server loads no plugins and launches no MCP servers or local processes; it is a single Go binary talking to the Kubernetes API. Container images the model asks pods_run to start run inside the cluster, not in the server, and are scored as code execution under C4 and tool scope under C3.

Protocol logs pass through a regex-based sanitizer and sensitive config options are redacted when the configuration is dumped, and telemetry is off unless an endpoint is set. But the model-bound path is unprotected: the default configuration_view tool returns the flattened kubeconfig without redaction (tokens and client keys included) in stdio mode, and Secret objects come back in full through the generic resource tools. Those are long-lived, often cluster-admin credentials.

In the default configuration the server keeps no record of tool calls: names and arguments are logged only at verbosity 5 and results at 6, while the default verbosity is 0, and OpenTelemetry tracing is off unless an endpoint is configured. When enabled, logs carry tool name, sanitized arguments, and results, and spans carry tool name and status, but there is no actor attribution beyond user agent and no tamper-evidence. Kubernetes API audit logs on the cluster side are not the server's own record.

The server bounds little of its own work. Pod logs default to the last 100 lines but the caller can raise that, list and get operations have no size limits, exec output is buffered without a cap or timeout, and the per-session rate limiter is disabled by default. Request contexts are passed to exec streaming, so a cancelled MCP request should stop in-flight exec, but nothing enforces a ceiling.