Scanner Form
The Scanner form provisions a new scanner. After submission the page transitions into a guided installation flow with a one-time provisioning token, a curl command, and inline trust-verification steps for each step of the install. Scanners are stateless Go binaries that run on customer networks and pull jobs from the manager. Scanners are edited inline on the parent list page — there is no standalone Edit form.
Inputs
| Name | Description | Allowed values | Default |
|---|---|---|---|
Name | Human-readable scanner label, used in scan results and audit logs | Letters, numbers, hyphens, underscores; must be unique across scanners (e.g., "datacenter-scanner-1") | — |
IP Binding Mode | Restricts which client IP can authenticate as this scanner. Defense-in-depth against stolen credentials. | ip (exact-match) | subnet (/24 IPv4 or /64 IPv6) | asn (same provider, e.g. AWS) | none (no restriction) | ip |
Description | Optional note about this scanner (location, network, owner) | Any text, max 10,000 characters | Empty |
Gotchas
- After submission the page does NOT navigate away — it transitions into a "Scanner Created" view with the provisioning token, install command, and step-by-step trust verification. Don't close the tab until you've copied the curl command — the token expires in 1 hour and can only be used once.
- Choose IP Binding Mode based on how the scanner connects: "ip" if it has a static IP; "subnet" if it sits behind a NAT or DHCP-assigned address inside a known network; "asn" for cloud workloads where IPs change but the provider is stable; "none" only if you have other auth controls and need maximum flexibility.
- There is no /config/scanners/:id/edit page — the route exists as a redirect to the parent list. To rename, change description, or rotate keys for an existing scanner, use the inline editing on the Scanners list page (description column is editable; row actions cover bind/regenerate/rotate/disable).
- The install script SHA-256 is shown in the post-submission view so the operator can verify the script before running it on the target host. This is part of the trust contract — never run the install command without verifying the hash matches. The install-script SHA-256 and the binary's Ed25519 signature are the two halves of the trust contract — the script hash comes from the modal, the binary signature verifies against scanner.pub pinned from the source repo.
- Names cannot be reused even after a scanner is deleted (the audit history retains the old name). Pick names that describe location or purpose, not sequence numbers that may collide.
API calls (4)
| Method | Path | Description |
|---|---|---|
| POST | /api/config/scanners | Create a new scanner and receive a provisioning token |
| GET | /api/config/scanners/binary-hash | Trust-verification: scanner binary SHA-256 |
| GET | /api/config/scanners/install-script-preview | Trust-verification: the install script the curl command will execute |
| GET | /api/config/scanners/source-code | Trust-verification: scanner source code (Go, stdlib only) |
Related
- Scanners — Parent list page — also describes inline editing, key rotation, and disable/enable flows
- Scanner Groups — Group multiple scanners for multi-vantage-point scanning
- Scanners (Health) — Real-time health and connectivity status after provisioning