Security Hardening

These practices harden a LyftData deployment so only trusted users and systems can interact with it.

TLS (HTTPS)

LyftData serves HTTPS by default (self-signed if you do not provide TLS material). For production, install a trusted certificate (or terminate TLS behind a reverse proxy).

• Built-in TLS: run the server with --tls-cert and --tls-key (or LYFTDATA_TLS_CERT / LYFTDATA_TLS_KEY).
• Reverse proxy: terminate TLS in a proxy and run the server with --disable-tls.
• Do not use insecure TLS in production: --tls-insecure / LYFTDATA_TLS_INSECURE applies to CLI and worker-to-server clients and is intended for evaluation/self-signed environments only.

See Networking & TLS for end-to-end verification checks.

Network boundaries

• Keep the server bound to 127.0.0.1:3000 unless you explicitly need remote access.
• If you expose the server port, restrict it to management CIDRs (VPN/bastion) and block public networks.
• Segment traffic where possible: separate control plane and worker hosts and allow only required ports.

Example (UFW):

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow from 10.0.0.0/8 to any port 3000 proto tcp
sudo ufw enable

Accounts and secrets

• Run server and workers as dedicated service accounts with isolated data directories (see Prerequisites).
• Store secrets (admin bootstrap password, worker API keys) in service environment files with tight permissions.
• Encrypt disks/volumes that store staging data, logs, and backups where possible.

Workers and enrollment

• Prefer unique API keys per worker and rotate them on a schedule.
• Use auto-enrollment (LYFTDATA_AUTO_ENROLLMENT_KEY) only on trusted networks; rotate or disable the shared secret after provisioning.
• Keep the server URL scheme consistent (https://… by default; http://… only when running the server with --disable-tls).

See Worker Authentication for the tradeoffs.

Optional: allowlisted collectors

If you need a trusted collector to scrape worker logs/metrics without an admin token, configure the server whitelist (--whitelist / LYFTDATA_API_WHITELIST) and keep the allowlist tight (specific source IPs only). This bypass applies only to selected worker read endpoints and still requires the Authorization: WHITELIST header.

Incident response checklist

1. Isolate impacted workers/servers from the network.
2. Rotate worker API keys, auto-enrollment secrets, and TLS certificates.
3. Restore from a known-good backup (see Backup & recovery).
4. Review logs and recent configuration changes to determine cause and scope.

Security is ongoing; integrate these hardening steps into your deployment automation and revisit them regularly.