Skip to content
LyftData Docs

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):

Terminal window
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.

For headless Linux servers, prefer explicit env-backed master keys for the variables store and credential manager instead of relying on an interactive OS keyring:

  • LYFTDATA_VARIABLES_MASTER_KEY_SOURCE=env
  • LYFTDATA_CREDENTIAL_MANAGER_MASTER_KEY_SOURCE=env

Keep the corresponding key values only in a root-owned env file with 0600 permissions.

systemd hardening (Linux)

For production Linux hosts, prefer a reverse-proxied systemd unit that:

  • runs as a dedicated non-login account
  • keeps the service bound to 127.0.0.1:3000
  • uses a root-owned environment file for secrets
  • sets UMask=0077
  • enables NoNewPrivileges=true, PrivateTmp=true, PrivateDevices=true, ProtectSystem=strict, and ProtectHome=true
  • leaves CapabilityBoundingSet= empty and narrows ReadWritePaths to the service state directory

After changing the unit, validate both the service and the sandbox posture:

Terminal window
systemctl status lyftdata --no-pager
curl http://127.0.0.1:3000/api/liveness
systemd-analyze security lyftdata.service

See Server Installation on Linux for a concrete hardened unit example.

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.