Agent-Hellboy / Agent-Hellboy/mcp-runtime

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

Abierto
#52 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Go
Estrellas
6
Forks
1
Merge medio
11 h 33 min
PR fusionados (30 d)
13

Descripción

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.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.