This document outlines security considerations for the Jarvis deployment.

Auth keys are stored in .env files that are gitignored:

• production/.env - Contains TS_AUTHKEY
• beta/.env - Contains TS_AUTHKEY_BETA

When loading .env files in shell scripts (like manage.sh), the project uses a secure parsing method:

set -a
[ -f ".env" ] && source ".env"
set +a

Do not use export $(cat .env | xargs) or similar constructs, as they create injection vulnerabilities if secrets contain spaces or shell metacharacters.

Tailscale auth keys should be rotated:

• Immediately if compromised
• Every 90 days (keys are set to expire after 90 days by default)
• When team members leave

To restrict services to Tailscale-only access:

# In docker-compose.yaml, change:
ports:
  - "0.0.0.0:8080:80"   # LAN accessible
# To:
ports:
  - "127.0.0.1:8080:80" # Localhost only (Tailscale still works)

The Tailscale sidecar containers run in privileged mode:

tailscale-sidecar:
  privileged: true

This is required for Tailscale to:

• Create TUN devices
• Modify network routing tables
• Manage DNS settings

The Open WebUI container logs a warning:

WARNING: CORS_ALLOW_ORIGIN IS SET TO '*'

For production deployments with known clients, consider setting specific origins:

environment:
  CORS_ALLOW_ORIGIN: "https://jarvis.yourtailnet.ts.net"

1. Auth Keys: Use separate keys for production and beta
2. Key Options: Always create keys with "Reusable" + "Ephemeral"
3. Device Approval: Review connected devices regularly at https://login.tailscale.com/admin/machines
4. Updates: Keep Tailscale and Open WebUI updated for security patches
5. Backups: Backup volume data before major updates

• Auth keys are not committed to git
• Auth keys use "Reusable" + "Ephemeral" options
• Separate keys for production and beta
• Reviewed connected Tailscale devices
• Considered restricting ports to 127.0.0.1 if LAN access not needed
• Documented any custom CORS origins