Skip to main content

Security Hardening: Docker Socket & MCP Orchestration

⚠️ The Critical Vulnerability (R-01)​

The current implementation of chat-server and its MCP (Model Context Protocol) orchestration poses a High/Critical security risk to the host infrastructure.

Description​

The chat-server container mounts the host's Docker socket (/var/run/docker.sock) and includes the Docker CLI. The configuration in mcp_services.json allows the backend to execute docker run commands dynamically.

Why is this critical?​

If the chat-server (an internet-exposed Python FastAPI application) is compromised via an RCE (Remote Code Execution) or a library vulnerability, the attacker gains full root-level control over the host Docker daemon. An attacker can:

  1. Escape the container: Launch a new privileged container and mount the host's root filesystem.
  2. Destructive Actions: Delete all other containers and volumes (databases, backups).
  3. Lateral Movement: Access any other service in the private network.
  4. Exfiltration: Read environment secrets and configurations of all other services.

🛡️ Remediation Strategies​

Strategy 1: Docker Socket Proxy (Fast Hardening)​

Instead of mounting the socket directly, use a security-focused proxy.

  • Implementation: Add tecnativa/docker-socket-proxy as a service in the main stack.
  • Benefits: Restricts the API to READ and CREATE operations, blocking DELETE or EXEC on host-level resources.
  • Action: Change the chat-server connection from the unix socket to an HTTP connection pointing to the proxy.

Strategy 2: Worker Pattern (Isolation)​

Move the "privileged" actions to a non-exposed worker.

  • Implementation:
    1. chat-server ceases to have Docker access.
    2. An internal mcp-worker is created (unreachable from the outside).
    3. chat-server sends "Run MCP" commands to Redis.
    4. mcp-worker consumes the queue and manages the Docker lifecycle.
  • Benefits: If the web-facing server is hacked, the attacker has no paths to the Docker daemon.

Strategy 3: Sidecar / HTTP Transport (Long Term)​

Remove the need for docker run on-demand for critical services.

  • Implementation:
    • Change thingsboard and other MCPs to mode: internal and transport: http.
    • Define these MCPs as standard services in docker-compose.yml.
  • Benefits: No Docker orchestration needed at runtime; services stay isolated behind standard HTTP protocols.

🗺️ Implementation Roadmap​

Phase 1: Security Audit Fix​

  • Implement Docker Socket Proxy for dev/staging.
  • Migrate subsystems.json credentials to .env.secrets.

Phase 2: Architectural Transition​

  • Evaluate performance of "Always-on" vs "On-demand" MCP containers.
  • Transition thingsboard MCP to an internal HTTP service.
  • Remove /var/run/docker.sock from the chat-server definition.

Phase 3: Runtime Hardening​

  • Change chat-server and user-service Dockerfiles to use a non-root user (USER appuser).
  • Apply read_only: true to the source code volumes in production.

Created on 2026-03-26 - Security Audit Report