Agent-Hellboy / Agent-Hellboy/mcp-runtime
Add CLI: Admin-generated kubeconfig/token for “MCP Server Deployer” in mcp-servers (deploy + status visibility)
- Lingua principale
- Go
- Stelle
- 6
- Fork
- 1
- Merge medio
- 11h 33m
- PR unite (30g)
- 13
Descrizione
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.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Valutazione
Questa issue non è ancora stata valutata.