Security: Docker socket exposure and privileged container in example configuration

[youming1970]

Hi Chronos team,

While reviewing the Docker example configuration in , I've identified several security concerns that could pose risks in production environments:

Security Issues Identified

1. Docker Socket Exposure (Critical)

Lines 11, 21, 31, 41, 51, 61, 74: All containers mount Docker socket:

volumes:
  - '/var/run/docker.sock:/var/run/docker.sock'

Risk: This grants containers full Docker daemon access, equivalent to root privileges on the host system.

2. Privileged Container (Critical)

Line 65: cAdvisor runs in privileged mode:

cadvisor:
  privileged: true

Risk: Bypasses all security restrictions, allowing container breakout.

3. Host Filesystem Exposure (High)

Lines 72-76: Extensive host filesystem mounts:

- /:/rootfs:ro
- /sys:/sys:ro  
- /var/lib/docker/:/var/lib/docker:ro

4. Default Credentials (Medium)

Lines 106-108: Grafana uses default security settings without authentication.

Recommended Solutions

1. Remove Unnecessary Docker Socket Access

Most microservices (auth, client, items, inventory, orders, event-bus) don't need Docker socket access:

auth:
  build: './auth'
  container_name: 'auth'
  ports:
    - '3000:3000'
  # Remove Docker socket mount

2. Use Non-Privileged cAdvisor

Replace privileged mode with specific capabilities:

cadvisor:
  image: gcr.io/cadvisor/cadvisor:v0.47.0
  # Remove privileged: true
  cap_add:
    - SYS_ADMIN
  security_opt:
    - apparmor:unconfined

3. Add Security Documentation

Include a security section in README explaining:

• Why Docker socket access is limited to specific services
• Production security considerations
• Alternative deployment methods for production

Impact

Current configuration in production could allow:

• Container escape to host system
• Privilege escalation attacks
• Unauthorized access to host resources
• Data exfiltration through Docker daemon access

Proposed Changes

I'm happy to submit a PR with:

1. Minimal Docker socket access (only where truly needed)
2. Non-privileged container configurations
3. Security best practices documentation
4. .env file for configurable credentials

This would maintain functionality while following Docker security best practices.

Context: Configuration Security Review Team - helping projects maintain secure-by-default examples.