0 Fork 0

mirror of https://github.com/jhd3197/ServerKit.git synced 2026-11-09 05:24:49 +09:00

Files

T

Juan DenisandClaude Opus 4.8 eab1a35794 docs: sync docs with dev, add CHANGELOG/SECURITY, document Windows agent

dev was ~149 commits ahead of the last release with no changelog and several
stale docs. This brings the user-facing docs in line with what actually ships.

New:
- CHANGELOG.md — curates the unreleased panel work (agent fleet, plugins,
  status pages, cloud provisioning, RHEL support, installer hardening).
- agent/CHANGELOG.md — the agent release workflow links to this on every
  published release; it was a broken link. Now documents the agent's
  independent release line.
- SECURITY.md — vulnerability reporting policy + agent trust model
  (agent.key is host-equivalent; Features.Exec off by default; single-worker).

Fixes:
- Stale version stamps: docs/README.md and docs/API.md said 0.9.0 -> 1.6.7.
- Supported OS: README/INSTALLATION said Ubuntu/Debian only; installer also
  covers Fedora and RHEL/Rocky/AlmaLinux.
- Dead links/placeholders: API.md wiki link, INSTALLATION.md "yourusername".
- Windows agent + short-code pairing were undocumented; added to README,
  agent/README.md, and docs/pairing.md (incl. corrected host-stable
  credential-key derivation — USERNAME was dropped in agent 1.6.14).
- Documented the single gevent-websocket-worker deployment constraint in
  CLAUDE.md and docs/ARCHITECTURE.md.
- CONTRIBUTING.md: removed reference to a non-existent frontend test suite.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-05-31 14:38:15 -04:00

2.5 KiB

Raw Blame History

Security Policy

Supported Versions

ServerKit is under active development. Security fixes are applied to the latest release line and the main branch.

Version	Supported
1.6.x	✅
< 1.6	❌ (please upgrade)

The agent is versioned independently (agent-vX.Y.Z); always run a recent agent build, as several Windows service and credential-handling fixes landed in the 1.6.x line.

Reporting a Vulnerability

Please report security issues privately — do not open a public issue for anything exploitable.

Preferred: open a GitHub Security Advisory
We aim to acknowledge reports within a few days and to provide a remediation timeline after triage.

Please include affected version(s), reproduction steps, and impact. Coordinated disclosure is appreciated — give us a reasonable window to ship a fix before any public write-up.

Agent Trust Model

The multi-server agent is powerful by design — operators should understand its trust boundaries:

agent.key is a host-equivalent secret. Agent API credentials are stored AES-256-GCM encrypted under a key derived from host-stable identifiers (hostname + machine ID on Linux, hostname + computer name on Windows). Anyone who can read this file on the host — or recreate the host-derived key — can recover the credentials. Protect it like a root/SYSTEM secret.
Remote command execution is gated. Arbitrary command execution (system:exec) and interactive PTY sessions are controlled by the agent's Features.Exec flag, which is off by default. Enable it only on servers where you intend the panel to run shell commands.
Transport & connection controls. Agents authenticate to the panel with per-connection HMAC-SHA256 (with nonce/replay protection and a timestamp-skew check), and the panel enforces a per-server IP allowlist. Use wss:// (TLS-terminated) in production.
SERVERKIT_INSECURE_TLS=true disables certificate verification for all agent connections. It is intended for local development/testing only — never set it in production.

For a detailed internal audit of the panel, see SECURITY_AUDIT.md.

Deployment Note

The agent gateway keeps all connected-agent state in-memory in a single process. Run the panel with a single gevent-websocket worker; multi-worker deployments can misroute agent commands. See docs/ARCHITECTURE.md.