Skip to content

TokenFuse v0.3.0 — RBAC & alerts, mutual TLS, security hardening

Choose a tag to compare

View all tags
@TAIPANBOX TAIPANBOX released this 02 Jul 23:37
· 456 commits to main since this release
v0.3.0
c47c271
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Third release. Builds on v0.2.0 (HA cluster, hosted Cloud, MCP credential-broker) by clearing the entire optional-hardening backlog — the enforcement, security, HA, and Cloud layers are now feature-complete for a young project.

Highlights since v0.2.0

Hosted Cloud

  • RBAC — API keys are now key:org[:role] with admin (default) / viewer roles. Reads and ingest work for any valid key; mutations (kill, set-budget) require admin → 403 for a viewer, 401 for an unknown key. Orgs stay isolated. (#51)
  • Budget alerts — GET /v1/alerts flags runs that have spent ≥ a fraction of their central budget (TOKENFUSE_CLOUD_ALERT_PCT, default 0.8, or ?pct=). The dashboard shows an alert count and a ⚠ on near-budget runs. (#51)
  • Durable store — control-plane state (aggregates, kills, budgets) survives a restart via a JSON snapshot + 2 s autosave, zero external deps (TOKENFUSE_CLOUD_DATA). (#49)

HA cluster

  • Mutual TLS — on top of server TLS + bearer token, a node can require a CA-signed client certificate from every peer (rustls WebPkiClientVerifier, server::serve_mtls); each node presents its own cert via TOKENFUSE_CLUSTER_CLIENT_CERT/_KEY. Cryptographic peer authentication — an unauthenticated TCP client can't complete the handshake. Enable with TOKENFUSE_CLUSTER_MTLS_CA or serve --mtls-ca. (#52)
  • Linearizable follower reads — read_run_linearizable / GET /api/read-linear/{run} / Client::read_linear. (#47)

MCP credential-broker

  • Response redaction + stdio transport — secrets are redacted from tool responses so a result can't leak a credential into the model's context; a newline-delimited JSON-RPC stdio transport (mcp-broker --stdio) joins the HTTP one. (#50)
  • Broker hardening — DLP on outgoing tool arguments (TOKENFUSE_MCP_DLP) and a rug-pull lockfile (TOKENFUSE_MCP_LOCK). (#46)

Security hardening pass (#53)

  • Request-body size limit on the gateway and broker routers (DefaultBodyLimit, TOKENFUSE_MAX_BODY_BYTES, default 16 MiB).
  • Upstream connect timeout (TOKENFUSE_UPSTREAM_CONNECT_TIMEOUT_SECS). No whole-request timeout — SSE responses may run for minutes.
  • A cargo audit CI job (workspace + cluster).
  • Optional wasmtime 27 → 43 (the wasm feature is off by default and not in the shipped image), clearing 15 advisories incl. two critical Cranelift/Winch sandbox-escape issues. cargo audit is now green (0 vulnerabilities).
  • New threat model: docs/13-security-hardening.md — trust boundaries, implemented controls, the deliberate fail-open rationale, and an honest statement that this is an in-house hardening pass, not an independent third-party audit.

Images (GHCR, all public)

  • ghcr.io/taipanbox/tokenfuse:v0.3.0 · :latest — the gateway (drop-in proxy)
  • ghcr.io/taipanbox/tokenfuse:cluster — gateway + raft HA (--features cluster)
  • ghcr.io/taipanbox/tokenfuse-control-plane:v0.3.0 — the Cloud control plane
  • ghcr.io/taipanbox/tokenfuse-dashboard:v0.3.0 — the Next.js dashboard

Tests

Workspace 100 · cluster 12 (incl. mTLS) · Python SDK 11 · cargo audit 0 vulnerabilities · clippy/fmt clean.

Known limits (deferred, not blockers)

SQL/columnar Cloud store for scale; automated cert rotation / SPIFFE identity for the mesh; an independent third-party security audit before any "GA" claim.

Assets 2
Loading