Security Hardening

These practices tighten a default Lyft Data deployment so only trusted users and systems can interact with it.

Security properties

Transport security ready - run the server with --tls-cert/--tls-key (or the LYFTDATA_TLS_CERT/LYFTDATA_TLS_KEY env vars) to serve HTTPS. Workers and CLIs validate certificates by default and only drop to insecure mode when you set the hidden LYFTDATA_TLS_INSECURE override, so leave it unset in production.
Tokenised APIs - every REST route is wrapped with role-specific JWT filters. Tokens are signed with LYFTDATA_JWT_PSK, and invalid or role-mismatched requests are rejected before handler code executes.
Workers require credentials - the worker CLI will not start unless it receives an API key or auto-enrolment secret. During bootstrap it exchanges those credentials for short-lived JWTs, keeping unauthenticated workers from connecting silently.
Signed job bundles enforced - workers verify each job’s DSL IR bundle and refuse to stage tampered payloads. Build without the default strict-signature feature only if you have a controlled test scenario that requires it.
Auto-generated signing secrets - if LYFTDATA_JWT_PSK is absent at startup the server prints and stores a fresh 30-character secret, so there is never a shared default key. Persist the generated value (or set your own) to keep issued tokens valid across restarts.

Allow only required ports (server API, worker API, SSH). Example with UFW:

sudo ufw allow 22/tcp
sudo ufw allow 3000/tcp    # server API (internal only)
sudo ufw deny 3000/tcp     # block from public networks
sudo ufw enable

Segment traffic: keep the control plane, workers, and backing databases in separate subnets or security groups and restrict cross-segment traffic to the minimum required ports.
Require VPN or bastion access for administration; lock the server port to management CIDRs.

Issue unique API keys for every worker and rotate them on a schedule. Store keys in environment files with chmod 600 and load them through your service manager.
Use auto-enrolment (LYFTDATA_AUTO_ENROLLMENT_KEY) only on trusted networks. Audit the list of registered workers after enabling it and disable the key when you are done provisioning.
Enable TLS on the control plane with either CLI flags or environment variables:
Terminal window
```
lyftdata run server \
  --tls-cert /etc/lyftdata/certs/server.crt \
  --tls-key /etc/lyftdata/certs/server.key
```
Point workers at the HTTPS URL (LYFTDATA_URL=https://lyftdata.example.com) and ensure the certificate chain is trusted on each host.
Restrict unauthenticated access to metrics/log endpoints with the server --whitelist flag (LYFTDATAD_WHITELIST env) or by placing the server behind a reverse proxy that enforces IP allow-lists and auth for admin routes.
Add HTTP basic auth or SSO at the proxy layer for the UI if your deployment runs on a shared management network.

Encrypt disks or volumes that store staging data, backups, and logs (LUKS, encrypted EBS/EFS, etc.).
Terminate TLS at the server or a reverse proxy; renew certificates automatically (Let’s Encrypt, ACM, Vault, etc.).
Encrypt sensitive columns in downstream databases when exporting data (for example, pgp_sym_encrypt in Postgres).

Forward server and worker logs to your SIEM; monitor for unusual login attempts and configuration changes.
Enable shell history logging or configuration management to track changes to server.yaml and unit files.
Periodically review context changes in the Context workspace or by calling /api/contexts/global to ensure secrets haven’t drifted.

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