kite - Moses Yebei

Abstract

🪁 A lightweight, modern Kubernetes dashboard that unifies multi-cluster and resource management, enterprise-grade user governance (OAuth, RBAC, and audit logs), and AI agents in one workspace. Not just a tool, but more like a platform.

The Problem

Operators need a single UI that can view, edit, and act on resources across many Kubernetes clusters while enforcing enterprise‑grade access controls. Existing dashboards either lack multi‑cluster support or require separate tools for RBAC, audit logs, and AI‑assisted troubleshooting, forcing teams to stitch together ad‑hoc scripts.

What This Does

kite delivers a full‑stack platform: a Go‑based API server (main.go) and a React/TypeScript front‑end (ui/src). The back‑end implements OAuth, RBAC, audit logging and proxies to the Kubernetes API (see pkg/auth/handler.go, pkg/rbac/*.go, pkg/kube/client.go). The UI talks to the API via the generated client in ui/src/lib/api.ts and renders resource tables, live charts, logs and an AI chat assistant (pkg/ai/handler.go). Helm charts (charts/kite/*.yaml) and Dockerfiles (Dockerfile, Dockerfile.binary) enable containerised deployment.

How It Is Wired

Process start – main.go:223 runs main, which initializes the DB (InitDB in pkg/model/model.go), creates the Kubernetes client (NewClient in pkg/kube/client.go), registers HTTP routes (setupAPIRouter in pkg/auth/handler.go) and starts the HTTP server.
Routing – setupAPIRouter registers handlers such as NewAuthHandler, NewGenericResourceHandler, and AI endpoints (HandleChat, HandleExecute). Each route is a hub; e.g., RegisterRoutes -> NewGenericResourceHandler occurs 27 times, giving generic_resource_handler.go the highest fan‑in (23 callers).
Core request flow – A typical resource list request follows: HTTP → RegisterRoutes → NewGenericResourceHandler.List → Query (pkg/prometheus/client.go) → DB Exec → JSON response. The Query function is called from 12 places, making it a high‑impact node.
AI interaction – HandleChat (entry point) creates an Agent (pkg/ai/agent.go), which builds a runtime prompt (buildRuntimePromptContext) and calls the model client (NewAnthropicClient or NewOpenAIClient). The model call is the only outbound network call from the AI path.
External effects – DB writes: InitDB, Callback → Query, Create (resource creation). Network calls: Kubernetes client (client.Get), model APIs, Prometheus queries. * Filesystem: log streaming (pkg/kube/log.go), reading/writing config files.
Hotspots – ui/src/pages/resource-list imports 20 other modules but is only imported once, indicating high instability* (0.95). UI components button and card are pure leaf nodes (Ca = 10, Ce = 0). The most connected back‑end module is pkg/handlers/resources/cr_handler.go (9 functions, called from 23 files).

No circular import cycles were detected, so static dependencies are acyclic, simplifying refactoring.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/kite
cd kite

# Build the server (requires Go 1.25+)
make build          # produces ./kite (binary)

# Build the UI (pnpm required)
cd ui
pnpm install
pnpm run build      # outputs dist/ for the static assets

# Run locally with Docker (recommended)
docker build -t kite:local .
docker run -d -p 8080:8080 -v $(pwd)/data:/data \
  -e DB_DSN=/data/db.sqlite kite:local

Configuration lives in environment variables (DB_DSN, OAuth client IDs, Prometheus URLs) as documented in docs/config/*.md. The Helm chart (charts/kite/values.yaml) provides a production‑ready manifest; install with:

helm repo add kite https://kite-org.github.io/kite/
helm install kite kite/kite -n kube-system -f myvalues.yaml

Real‑World Use

A SaaS platform runs kite as a side‑car in each customer’s management cluster. The back‑end authenticates users via the provider configured in docs/config/oauth-setup.md, enforces per‑tenant RBAC (pkg/rbac/manager.go), and exposes an AI chat that can query Prometheus metrics and suggest scaling actions, all from a single UI.

Code Health & Issues

Critical – Privileged pull‑request checkout in .github/workflows/build-preview-docker-image.yml.
Critical – Secrets used in a fork‑triggered workflow .github/workflows/deploy-test-env.yml.
High – GitHub Actions not pinned to commit SHAs (docker/setup-qemu-action@v3, etc.).
High – Release workflow pushes directly to default branch (.github/workflows/release.yaml).
Medium – Base images referenced by mutable tags in Dockerfile.
Medium – No dependency‑vulnerability scan step in CI.
Medium – Checkout step retains token; should set persist-credentials: false.
Medium – Container runs as root; no non‑root USER defined.
Medium – Test coverage low (9 test files vs 269 source files).
Low – Workflow jobs lack explicit timeout-minutes.

Additional static findings: deep nesting (max depth 8) in several UI components, duplicated logic across AI helper files, and oversized files (ui/src/lib/api.ts, pkg/ai/tools.go). These are reported by the analysis and include suggested fixes.

The Bottom Line

kite is a well‑structured, full‑stack Kubernetes dashboard with solid modular separation between UI, API, and cluster interaction. It offers the needed multi‑cluster, RBAC, and AI features, but the repository contains serious CI/CD security gaps and limited test coverage that must be addressed before production deployment. Suitable for teams comfortable with Go and React who can invest in hardening the CI pipeline.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

404 files

TSX164
Go79
Markdown44
TypeScript24
YAML22
CSS9

ReactExpressDockerKubernetes

Module dependencies

The 10 most depended-upon modules of 190, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_ui_src_components_ui_button["button"] n1_ui_src_components_ui_card["card"] n2_ui_src_components_ui_badge["badge"] n3__src_components_action_table["action-table"] n4__src_components_simple_table["simple-table"] n5_ui_src_components_ui_alert["alert"] n6_ui_src_components_ui_chart["chart"] n7_ui_src_components_ui_label["label"] n8_i_src_components_ui_skeleton["skeleton"] n9_mponents_appearance_provider["appearance-provider"] n3__src_components_action_table --> n0_ui_src_components_ui_button n4__src_components_simple_table --> n0_ui_src_components_ui_button

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical2

high2

medium5

low2

Do not check out pull request code in a privileged workflowcritical

.github/workflows/build-preview-docker-image.yml

privileged trigger checks out the untrusted ref

This is the most reliably exploited Actions pattern: anyone opening a pull request gets code execution with your repository secrets.

Fix: Split into an unprivileged pull_request build and a workflow_run job that only consumes its artifact.

Keep secrets out of workflows a fork can triggercritical2 occurrences

.github/workflows/deploy-test-env.yml

KITE_TEST_HOST, KITE_TEST_AUTH

Contributor-controlled input reaches a job holding a publish token or cloud credential, so a pull request becomes credential exfiltration.

Fix: Move secret-using steps into a workflow_run job that never checks out pull request code, or gate on an environment with required reviewers.

Pin third-party GitHub Actions to a commit SHAhigh7 occurrences

.github/workflows

docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, pnpm/action-setup@v4

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Open a pull request instead of pushing to the default branchhigh

.github/workflows/release.yaml

git push

Automated commits land on the branch that deploys, with no test having run against the result.

Fix: Push to a bot branch and open a pull request, or restrict the push to a tag ref.

Pin the container base image by digestmedium3 occurrences

Dockerfile

node:20-alpine, golang:1.25-alpine, gcr.io/distroless/static (mutable tag)

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/build-preview-docker-image.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Expand the test suite; it cannot cover this codebasemedium9 occurrences

9 test files against 269 source files (ratio 0.033)

A reviewer reads "has tests" and assumes a safety net that covers two files out of eighty-five, which is how untested paths ship behind a green badge.

Fix: Add tests for the highest fan-in modules first.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/build-preview-docker-image.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.