Managing collectors

A collector is one enforcement point on your network. This is the lifecycle: enroll → approve → operate → upgrade → retire.

Enroll

You issue a per-collector enrollment code and run the installer on a Linux host. Two ways to get a code:

• As a customer admin: Collectors → Add collector gives you the code and a ready install command.
• As Kilasec staff: on the Tenants row for the customer, Issue collector code — saves signing in as the tenant.

The customer runs the one-liner on the host. The collector enrolls and lands in pending approval — its token works only for status polling; it can't inspect or ingest anything until approved.

Approve (the security gate)

Enrollment is intentionally out-of-band: a freshly-enrolled collector does nothing until a human approves it. Before you approve, the pending card shows three things to sanity-check:

• Source IP — did it come from where you expect?
• Host fingerprint — a stable identifier for the machine.
• User-agent — the installer/version that enrolled.

Verify those, then Approve. Approval is a signed-in user action (customer admin, or staff via "View as tenant") — a collector can't approve itself. Reject invalidates the token immediately.

If a collector enrolls but never heartbeats within ~10 minutes (e.g. the install half-failed), a sweeper auto-revokes it so the list doesn't fill with ghosts. Pending rows older than 24h are auto-rejected.

Operate

Once approved and heartbeating, a collector shows online (see Monitoring). From its detail panel you can:

• Download the CA certificate and copy the PAC URL (for network setup and CA distribution).
• Run a verify command to confirm interception.
• Set a source-IP allowlist — restrict which client IPs the collector will proxy for.

Apply policy / restart

Collectors pull policy and scope from the cloud. Most changes take effect on the collector's next pull. When you need them applied immediately, use Apply now on the Policy Rules page — it signals the collectors to restart and re-read config. A restart is graceful: buffers drain, then the container comes back (systemd Restart=always).

Upgrade

Collectors track the :latest image with pull_policy: always, so a restart pulls the current version. Rolling the image out is: publish the new image (CI does this from main), then restart the collector (Apply now, or a manual docker compose restart / systemd restart on the host). The version each collector is running is shown in Fleet health.

Retire

To remove a collector cleanly, use the drain-and-delete flow from its panel: the dashboard signals shutdown, the collector flushes its buffers, confirms, writes a shutdown sentinel so systemd won't resurrect it, and stops. The row is then purged. To simply cut one off, revoke its token — its next call returns 401.

Multiple collectors

Run one per site/subnet; each enrolls and is approved independently and appears separately in Fleet health. They share centrally-managed policy and scope, so more collectors is more coverage, not more admin. See Sizing & scaling.