Agent-Hellboy / Agent-Hellboy/mcp-runtime

Add CLI: Admin-generated kubeconfig/token for “MCP Server Deployer” in mcp-servers (deploy + status visibility)

Open
#52 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
6
Forks
1
Avg merge
11h 33m
Merged PRs (30d)
13

Description

We need a built-in CLI workflow for platform admins to generate a
shareable kubeconfig (short-lived token) for a platform user to
deploy/manage MCP servers in the mcp-servers namespace and view server
health/status/logs, without granting cluster-admin or access to other
namespaces.

Today this is done manually (create ServiceAccount + Role/RoleBinding
+ kubectl create token + hand-assemble kubeconfig). This is error-
prone and inconsistent.

———

## Requirements

### 1) CLI command

Add a command under cluster (or similar) to generate credentials, e.g.

- ./bin/mcp-runtime cluster access create --subject --namespace
mcp-servers --profile mcp-server-deployer --duration 8h --out
- Idempotent: re-running updates/ensures SA + bindings exist
- Writes kubeconfig to --out (avoid printing token by default)

### 2) Permissions (namespace-scoped)

The generated kubeconfig must allow the user to:

- Deploy/update/delete workloads required for MCP servers in mcp-
servers
- Read status and debug info in mcp-servers:
- list/get/watch pods/services/deployments
- fetch pod logs
- view events

It must not grant access outside mcp-servers (no cluster roles, no
cluster-wide list ns, no kube-system access).

Minimum RBAC in mcp-servers:

- Core: pods, pods/log, services, endpoints, configmaps, events
- Apps: deployments, replicasets, statefulsets, daemonsets
- Batch (optional): jobs, cronjobs
- Secrets: decide explicitly (default deny or read-only unless
required)

If MCP server deployment uses MCP Runtime CRDs (e.g. MCPServer), the
profile must also include the needed CRD resources/verbs in mcp-
servers.

### 3) Token generation

- Use kubectl create token --duration=
- Default duration: 8h (configurable)
- Document rotation/expiration guidance

### 4) Documentation

Add docs section describing:

- How admin generates kubeconfig
- What the platform user can/can’t do
- Example kubectl --kubeconfig … commands to deploy and check status/
logs

———

## Acceptance Criteria

- With generated kubeconfig:
- kubectl --kubeconfig X -n mcp-servers apply -f
succeeds
- kubectl --kubeconfig X -n mcp-servers get deploy,pods,svc
succeeds
- kubectl --kubeconfig X -n mcp-servers logs deploy/
succeeds
- Forbidden outside namespace:
- kubectl --kubeconfig X -n kube-system get pods fails with RBAC
Forbidden
- kubectl --kubeconfig X get ns fails (unless we explicitly choose
to allow it)

———

## Notes / Rationale

- This keeps cluster maintenance and setup with admins, while enabling
platform users to deploy MCP servers safely.
- Kubernetes RBAC is allow-only; we achieve isolation by binding roles
only in mcp-servers.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.