Reference
Security model
What sitescope protects, from whom, and how. A monitor sees everything, so it is built to be uninteresting to break into.
What it holds
- Read-only API tokens for the cloud provider and DNS host, and optionally a Cert Spotter key. Billing, record contents and token metadata, nothing that can change infrastructure.
- The agent token, which reads host facts. It goes
over WireGuard or loopback in plain HTTP. Anywhere else the agent should
serve TLS (
agent.tlsCert) with its own token (tokenEnvon the hub), so one compromised host can’t read another. - A picture of the infrastructure: hosts, addresses, versions, what is failing. Useful to an attacker, so the messages stay behind the detail view’s password, and the public page shows only the names and statuses you allow.
Rules it follows
Nothing it does changes the infrastructure. Tokens
are scoped read only, probes only ask, and the open-relay probe stops at
RCPT TO.
- Plaintext secrets never touch the disk. The vault is decrypted into locked memory; edits are encrypted before they are written.
- Secrets are never logged and never appear in error messages.
- No unlock from the web. Only a member of the admin group, on the hub host, through a mode 0660 socket.
- Secrets from outside the store. The environment
file is not in
/nix/store, where every user could read it. - The public page says only what you allow. Each check is public under a label, grouped into a service light, or private. Checks no rule matches are public under their own names, so add a catch-all private rule if names like hostnames must not show. Messages are never public.
Process hardening
| measure | effect |
|---|---|
mlock + MADV_DONTDUMP on the vault
buffer |
secrets aren’t swapped out or written to crash dumps |
PR_SET_DUMPABLE=0 |
no ptrace or /proc/PID/mem from same-user
processes |
LimitCORE=0, RLIMIT_CORE=0 |
no core files |
| buffers zeroed on lock, SIGTERM and exit | a locked hub holds no plaintext |
| separate users for hub and agent | the vault process has no capabilities |
| systemd sandboxing | see NixOS module |
Authentication
- Agents compare the bearer token in constant time.
- The detail view uses basic auth against a bcrypt (cost 12) hash stored in the vault, so a locked hub can’t authenticate anyone. Failures are limited to one per second.
- The control socket checks the caller with
SO_PEERCREDand logs it.
Known limits
- A token is copied to the Go heap while it is placed in an HTTP header, and age decrypts through a heap buffer. Neither is zeroed.
- Basic auth relies on the reverse proxy’s TLS.
- Anyone with root on the hub host can read its memory.