Security

Secure your application architecture by isolating services in separate networks. Not every service needs to talk to every other service! Default behavior: All connected By default, all services share the same network: # All services can communicate services: web: image: nginx api: image: myapi database: image: postgres Problem: web can directly access database - potential security risk! Network isolation pattern Create separate networks for different tiers: ...

Secure containers with principle of least privilege! Control exactly what your containers can do. Understanding capabilities Linux capabilities break down root privileges into distinct units: services: # Drop all capabilities, then add only what's needed secure-app: image: myapp cap_drop: - ALL cap_add: - NET_BIND_SERVICE # Bind to ports < 1024 - CHOWN # Change file ownership # Default Docker capabilities (for reference) default-app: image: myapp # Implicitly has: CHOWN, DAC_OVERRIDE, FSETID, FOWNER, # MKNOD, NET_RAW, SETGID, SETUID, SETFCAP, SETPCAP, # NET_BIND_SERVICE, SYS_CHROOT, KILL, AUDIT_WRITE Common capability patterns Web server (needs port 80/443): ...

Stop hardcoding passwords! Docker Compose secrets provide a secure way to handle sensitive data. Basic secret setup Define secrets and use them in services: secrets: db_password: file: ./secrets/db_password.txt api_key: file: ./secrets/api_key.txt services: app: image: myapp:latest secrets: - db_password - api_key environment: DB_PASSWORD_FILE: /run/secrets/db_password API_KEY_FILE: /run/secrets/api_key Secrets appear as files in /run/secrets/ inside containers. Reading secrets in your app Node.js example: ...

Choose the right networking mode for your containers. Understand when isolation matters and when performance is key. Bridge mode (default) The default and most secure option - containers get their own network namespace: services: web: image: nginx ports: - "8080:80" # Port mapping required networks: - app_network db: image: postgres:15 networks: - app_network networks: app_network: driver: bridge Containers can communicate using service names (web, db) within the network. ...

Running containers as root is a security risk. Configure your services to use non-root users for defense in depth. The problem By default, many containers run as root: services: app: image: nginx # Runs as root user (uid 0) - security risk! If compromised, attackers have root privileges inside the container. The solution Set the user in compose.yml: services: app: image: node:20 user: "1000:1000" # Run as uid:gid 1000 working_dir: /app volumes: - ./app:/app Or use the image’s built-in user: ...