Security Hardening

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

Use Access Control for principals, roles, tenant and environment scope, API keys, worker authority, and least-privilege reviews. Use Pipeline Integrity to follow a definition from authoring through staging, deployment, observed execution, and external receipts.

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.

Use Credentials and secrets for job-facing sensitive material. Ordinary context values are reusable configuration and must not be treated as a secret store.

For headless Linux servers, prefer explicit env-backed master keys instead of relying on an interactive OS keyring or DBus session. Set all three source variables in the service env file:

• LYFTDATA_VARIABLES_MASTER_KEY_SOURCE=env
• LYFTDATA_CREDENTIAL_MANAGER_MASTER_KEY_SOURCE=env
• LYFTDATA_SETTINGS_MASTER_KEY_SOURCE=env

Keep the corresponding key values (LYFTDATA_VARIABLES_MASTER_KEY, LYFTDATA_CREDENTIAL_MANAGER_MASTER_KEY, and LYFTDATA_SETTINGS_MASTER_KEY) only in a root-owned env file with 0600 permissions. The variables and credential-manager keys protect server-side state; the settings key protects built-in worker and external worker settings and credential transport.

Back up these keys separately from the staging directory. A state snapshot without its matching key may leave encrypted variables or credentials unreadable. See Credential lifecycle and recovery and Backup and recovery.

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:

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.