aliang-one/aliangboard

What it claims

AliangBoard (current release v1.0.3, Apache License 2.0) is a single-process Kubernetes panel. It has a Vue 3 frontend in plain JavaScript and a Node.js 25 API gateway. The gateway stores API keys, cluster credentials, the audit log and a git-backed workbench repository in SQLite. The agent and the MCP endpoint (POST /mcp) share one toolset, and each tier has concrete limits. The operator tier is limited to scale (1 to 20 replicas, never 0) and rolling restart. The admin tier covers exec, container file reads, apply and delete, image update, kubectl debug injection and rollback to a revision. Read tools include logs, list and get with YAML, events, a can-i RBAC self-check and rollout history.

How it works

Each API key maps to one ServiceAccount, so the SA's Kubernetes RBAC caps every tool call. A per-key minTier filters which tools the key sees. SSH servers are opt-in per server with an approval policy: always, readonly (read-only commands auto-allowed) or none. Keys need a separate boolean grant to reach wb_ssh_exec, wb_ssh_read_file and read_server_ledger. On the MCP key channel there is no human approver, so the always policy denies exec outright (fail-closed). SSH credentials are AES-256-GCM encrypted, with the key file stored apart from the database.

flowchart TD
  A[Agent console or MCP key] --> B[Bound ServiceAccount RBAC]
  B --> C{Tool tier}
  C -->|read| D[Runs directly]
  C -->|operator / admin| E{Human approver present?}
  E -->|yes, console| F[Approve, then run]
  E -->|no, MCP key + SSH 'always'| G[Denied]
  D --> H[Audit log]
  F --> H

How to use it

In-cluster install creates the aliangboard namespace, a NodePort Service and a 1Gi PVC from the default StorageClass:

kubectl apply -f https://raw.githubusercontent.com/aliang-one/aliangboard/main/deployment.yaml
kubectl -n aliangboard get svc aliangboard   # read the NodePort from the PORT(S) column, e.g. 8787:31234/TCP

Docker:

docker run -d --name aliangboard \
  -p 8787:8787 \
  -v aliangboard-data:/app/data \
  ghcr.io/aliang-one/aliangboard:latest

Connect Claude Code:

claude mcp add --transport http aliangboard {HOST}/mcp \
  --header "Authorization: Bearer <YOUR_API_KEY>"

The LLM is set with LLM_BASE_URL and LLM_MODEL or in "LLM Settings". The page names OpenAI, DeepSeek, Qwen, GLM, vLLM and Ollama. Images are multi-arch (amd64, arm64) and tagged latest, 1.2 (rolling minor) and 1.2.3 (immutable). A source build needs Node.js 25+, because node:sqlite needs --experimental-sqlite on Node 22 to 24. In-cluster, the default ServiceAccount has no RBAC and returns 403. A dedicated SA token (kubectl create token) and the cluster CA are required. The README lists the exact verbs for each feature, such as pods/ephemeralcontainers update for debug injection.

Limits

• The default login is admin/admin. ADMIN_USERNAME/ADMIN_PASSWORD apply only at first start, so changing them later has no effect.
• The SQLite store is single-replica, so replicas must not be scaled. kubectl delete ns aliangboard deletes the PVC and all data.
• The panel has no built-in TLS. NodePort is for internal evaluation only, and production needs TLS at an Ingress or proxy (deploy/ingress-tls.yaml). K8S_INSECURE_SKIP_TLS_VERIFY affects only cluster connections.
• Gateway sessions are in memory and lost on restart. Session credentials sit in browser localStorage, and the page warns against shared devices.
• Port-forward listens on the gateway host (default 127.0.0.1) and does not work for in-cluster installs.
• The README's "Audit" page shows cluster Events, not user-level auditing. Full who/verb/IP auditing needs Kubernetes audit logging sent to a log backend. This differs from the tool-call audit log described for the agent.
• SSH authorization is admin-only with no groups or per-user permissions. Helm, GitOps and alerting are not integrated. HPA and PDB creation fails on clusters without autoscaling/v2 and policy/v1.
• The public demo is shared, so anything entered there is visible to other visitors.