Security
This guide covers comprehensive security best practices for deploying TurboPanel. Securing both the control plane and agents is essential for production deployments. For setup instructions, see Control Plane and Agent Setup.
Introduction
TurboPanel's security model spans the control plane (management interface and API) and agents (remote Docker executors). Both components require attention to authentication, network isolation, and Docker socket access. This guide consolidates security guidelines from both components into a unified reference.
Control Plane Security
TLS/SSL Configuration
Production Requirement
For production deployments, always use a reverse proxy (nginx, Caddy, Traefik) for HTTPS. Never expose the control plane directly on HTTP in production.
# nginx example
server {
listen 443 ssl;
server_name turbopanel.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location / {
proxy_pass http://localhost:18282;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Authentication
The control plane implements:
- Token-based authentication for API access
- Agent token authentication for WebSocket connections
- Secure token storage and rotation policies
- Session management for web UI
Network Isolation
- Use Docker networks to isolate containers
- Restrict Docker socket access to necessary containers only
- Implement firewall rules to restrict access to port 18282
- Use VPN or private networks for agent communication when possible
- Consider Docker Swarm or Kubernetes network policies
Docker Socket Security
Docker Socket Access
The Docker socket provides full daemon access. Any process with socket access can create, destroy, or modify all containers and images on the host. Use network isolation, authentication, and audit logging.
Mitigation strategies:
- Run control plane in isolated Docker network
- Use Docker socket proxy for read-only access if applicable
- Implement audit logging for Docker operations
- Regularly review and rotate credentials
- Monitor Docker daemon logs for suspicious activity
- Consider Docker context restrictions
Token Management
- Store tokens in environment variables or secrets manager
- Never commit tokens to version control
- Implement token rotation policies
- Use strong, unique tokens for each agent
- Monitor token usage and revoke compromised tokens
- Use secrets management (Docker secrets, Kubernetes secrets, etc.)
Firewall Rules
Recommended:
- Allow inbound to port 18282 only from trusted networks
- Restrict outbound to necessary services only
- Block direct Docker socket access from external networks
- Use fail2ban or similar for brute-force protection
- Implement rate limiting on API endpoints
Non-Root User
The container runs as non-root (turbopanel:turbopanel, UID 9999). The Dockerfile creates this user and switches before running the application.
Agent Security
Authentication
- Agent Token: Use
AGENT_TOKENenvironment variable for authentication with the control plane - Token Rotation: Implement token rotation policies in production
- Token Storage: Store tokens securely (secrets manager, environment injection); never in code or image
Network Security
Production Requirement
Use HTTPS/WSS for production deployments. Never use plain HTTP/WSS for agent-to-control-plane in production.
- TLS/SSL: Use HTTPS/WSS for production deployments
- Network Isolation: Run agents in isolated networks when possible (Docker networks, VPC)
- Firewall Rules: Restrict agent port (18284) to control plane only; block unnecessary inbound/outbound
Docker Socket Security
- User Permissions: Agent runs as non-root user (
turbopanel:turbopanel, UID 9999) - Socket Binding: Only bind socket to necessary containers; avoid exposing socket to other services
Best Practices
- Use strong, unique tokens for each agent
- Enable TLS/SSL in production
- Monitor agent connections and activity (logs, metrics)
- Implement rate limiting on control plane for agent endpoints
- Regularly rotate authentication tokens
- Use network policies to restrict agent communication to control plane only
Security Layers Overview
graph TD
subgraph "External"
A[Client / Agent] --> B[Network Layer]
end
subgraph "Network"
B --> C[TLS/SSL]
C --> D[Firewall]
end
subgraph "Application"
D --> E[Authentication]
E --> F[Token Validation]
F --> G[Authorization]
end
subgraph "Host"
G --> H[Docker Socket]
endSecure Deployment Example
# Control plane behind nginx with TLS
# nginx handles SSL termination and proxies to localhost:18282
# Agent with token from secrets, WSS to control plane
docker run -d \
--name turbopanel-agent \
-p 18284:18284 \
-e AGENT_MODE=websocket \
-e CONTROL_PLANE_URL=wss://turbopanel.example.com \
-e AGENT_TOKEN=$(cat /run/secrets/agent_token) \
-v /var/run/docker.sock:/var/run/docker.sock \
turbopanel/agent:latest# Agent connecting to cloud control plane
docker run -d \
--name turbopanel-agent \
-p 18284:18284 \
-e AGENT_MODE=durable-objects \
-e CONTROL_PLANE_URL=https://your-control-plane.workers.dev \
-e AGENT_TOKEN=$(cat /run/secrets/agent_token) \
-v /var/run/docker.sock:/var/run/docker.sock \
turbopanel/agent:latestAgent hardening
- Firewall: Restrict the host firewall so port 18284 only accepts traffic from the control
plane IP or CIDR range. - Read-only socket: When an agent only needs read operations
(inspection, logs), mount the Docker socket read-only:
-v /var/run/docker.sock:/var/run/docker.sock:ro. Agents that must create or modify containers require full socket access.
Related Documentation
- Control Plane — Installation and configuration
- Agent Setup — Agent deployment for both modes
- REST API Reference — API structure and authentication
Last updated on