OpenClaw Security Checklist for Production

# Checklist:
☐ OpenClaw is NOT bound to 0.0.0.0 on public internet
☐ Use Tailscale, VPN, or private network instead
☐ Firewall rules restrict ports (only 443/80 if using reverse proxy)
☐ TLS/HTTPS enabled with valid certificates
☐ Reverse proxy configured (nginx/Caddy) with rate limiting
☐ DDoS protection enabled (Cloudflare, AWS Shield, etc.)
☐ Network segmentation: OpenClaw in isolated subnet

# Checklist:
☐ Running as non-root user (UID 1000, not 0)
☐ Read-only filesystem enabled
☐ Resource limits configured (CPU, memory)
☐ Health checks enabled
☐ Capabilities dropped (cap_drop: ALL)
☐ Secrets managed via Docker secrets or external vault
☐ Image scanning enabled (Trivy, Snyk, etc.)
☐ Base image is minimal (Alpine or distroless)
☐ No sensitive data in image layers

# Checklist:
☐ Gateway authentication enabled (API keys, OAuth, JWT)
☐ API keys rotated regularly (90 days max)
☐ Rate limiting configured per user/key
☐ IP allowlisting for admin endpoints
☐ No default/demo credentials in production
☐ Audit logging for all auth events
☐ MFA required for admin access
☐ Service accounts use unique credentials
☐ Secrets never in environment variables (use vault)

# Checklist:
☐ All skills manually audited before installation
☐ Skill permissions reviewed (filesystem, network, shell)
☐ Skills pinned to specific versions (no auto-updates)
☐ Unused skills removed
☐ Skill update policy documented
☐ Skills run in isolated environments when possible
☐ Prompt injection defenses configured
☐ Output filtering prevents credential leakage

# Checklist:
☐ Centralized logging (Elasticsearch, Loki, etc.)
☐ Failed authentication attempts logged and alerted
☐ Unusual API usage patterns monitored
☐ Container health metrics tracked
☐ Security alerts sent to on-call team
☐ Disk space monitoring (prevents log-based DoS)
☐ Network traffic anomalies detected
☐ Prompt injection attempts logged
☐ API key usage tracked per key

# Checklist:
☐ Daily automated backups of data volumes
☐ Backups stored off-site (S3, GCS, etc.)
☐ Backup restoration tested quarterly
☐ Configuration as code (docker-compose, IaC)
☐ RTO (Recovery Time Objective) defined
☐ RPO (Recovery Point Objective) defined
☐ Incident response playbook documented
☐ Disaster recovery tested in staging