Ein Post getaggt mit "DevOps"

In Startups im Silicon Valley ist Docker Compose eines der bevorzugten Tools für die schnelle Bereitstellung und Verwaltung containerisierter Anwendungen. Bequemlichkeit geht jedoch oft mit Sicherheitsrisiken einher. Als Site Reliability Engineer (SRE) bin ich mir bewusst, dass Sicherheitslücken zu katastrophalen Folgen führen können. Dieser Artikel teilt die besten Sicherheitspraktiken, die ich in meiner tatsächlichen Arbeit bei der Kombination von Docker Compose mit Ubuntu-Systemen zusammengefasst habe, um Ihnen zu helfen, die Vorteile von Docker Compose zu nutzen und gleichzeitig die Systemsicherheit zu gewährleisten.

I. Härtung der Ubuntu-Systemsicherheit​

Vor der Bereitstellung von Containern ist es entscheidend, die Sicherheit des Ubuntu-Hosts selbst zu gewährleisten. Hier sind einige wichtige Schritte:

1. Ubuntu und Docker regelmäßig aktualisieren​

Stellen Sie sicher, dass sowohl das System als auch Docker auf dem neuesten Stand gehalten werden, um bekannte Schwachstellen zu beheben:

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker-Verwaltungsberechtigungen einschränken​

Kontrollieren Sie die Docker-Verwaltungsberechtigungen streng, um Privilege-Escalation-Angriffe zu verhindern:

sudo usermod -aG docker deployuser
# Verhindert, dass normale Benutzer leicht Docker-Verwaltungsberechtigungen erhalten

3. Ubuntu-Firewall (UFW) konfigurieren​

Beschränken Sie den Netzwerkzugriff angemessen, um unbefugten Zugriff zu verhindern:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker- und UFW-Interaktion korrekt konfigurieren​

Standardmäßig umgeht Docker UFW, um iptables zu konfigurieren, daher wird eine manuelle Steuerung empfohlen:

Die Docker-Konfigurationsdatei ändern:

sudo nano /etc/docker/daemon.json

Folgenden Inhalt hinzufügen:

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Den Docker-Dienst neu starten:

sudo systemctl restart docker

Adressen in Docker Compose explizit binden:

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose Sicherheit Best Practices​

Die folgenden Konfigurationen gelten für Docker Compose v2.4 und höher. Beachten Sie die Unterschiede zwischen Nicht-Swarm- und Swarm-Modus.

1. Container-Berechtigungen einschränken​

Container, die standardmäßig als Root laufen, bergen hohe Risiken; wechseln Sie zu Nicht-Root-Benutzern:

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000"  # Non-root user
    read_only: true    # Read-only filesystem
    volumes:
      - /tmp/app:/tmp  # Mount specific directories if write access is needed
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Erklärung:

• Ein schreibgeschütztes Dateisystem verhindert Manipulationen innerhalb des Containers.
• Stellen Sie sicher, dass gemountete Volumes auf die notwendigen Verzeichnisse beschränkt sind.

2. Netzwerkisolation und Port-Management​

Interne und externe Netzwerke präzise aufteilen, um die Offenlegung sensibler Dienste gegenüber der Öffentlichkeit zu vermeiden:

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• Frontend-Netzwerk: Kann öffentlich zugänglich sein.
• Backend-Netzwerk: Streng eingeschränkt, nur interne Kommunikation.

3. Sicheres Geheimnismanagement​

Sensible Daten sollten niemals direkt in Compose-Dateien abgelegt werden:

Im Einzelmaschinenmodus:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Im Swarm-Modus:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true  # Managed through Swarm's built-in management

Hinweis:

• Die nativen Swarm Secrets von Docker können externe Tools wie Vault oder AWS Secrets Manager nicht direkt nutzen.
• Wenn externer Geheimnisspeicher benötigt wird, integrieren Sie den Leseprozess selbst.

4. Ressourcenbegrenzung (An Docker Compose Version anpassen)​

Container-Ressourcenlimits verhindern, dass ein einzelner Container Host-Ressourcen erschöpft.

Docker Compose Einzelmaschinenmodus (v2.4 empfohlen):

version: '2.4'

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Docker Compose Swarm-Modus (v3 und höher):

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

Hinweis: In Nicht-Swarm-Umgebungen haben die Ressourcenlimits im deploy-Abschnitt keine Wirkung, achten Sie unbedingt auf die Compose-Dateiversion.

5. Container-Health-Checks​

Richten Sie Health-Checks ein, um Probleme proaktiv zu erkennen und Service-Ausfallzeiten zu reduzieren:

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. Vermeiden Sie die Verwendung des Latest-Tags​

Vermeiden Sie die Unsicherheit, die der latest-Tag in Produktionsumgebungen mit sich bringt, erzwingen Sie spezifische Image-Versionen:

services:
  api:
    image: your-image:1.4.0

7. Angemessenes Log-Management​

Verhindern Sie, dass Container-Logs den Festplattenspeicher erschöpfen:

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu AppArmor Konfiguration​

Standardmäßig aktiviert Ubuntu AppArmor, und es wird empfohlen, den Docker-Profilstatus zu überprüfen:

sudo systemctl enable --now apparmor
sudo aa-status

Docker unter Ubuntu aktiviert AppArmor standardmäßig ohne zusätzliche Konfiguration. Es wird im Allgemeinen nicht empfohlen, SELinux unter Ubuntu gleichzeitig zu aktivieren, um Konflikte zu vermeiden.

9. Kontinuierliche Updates und Sicherheitsscans​

• Image-Schwachstellenscans: Es wird empfohlen, Tools wie Trivy, Clair oder Snyk in den CI/CD-Prozess zu integrieren:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• Automatisierter Sicherheitsupdate-Prozess: Images mindestens wöchentlich neu erstellen, um bekannte Schwachstellen zu beheben.

III. Fallstudie: Lehren aus Docker Compose Konfigurationsfehlern​

Im Juli 2019 erlitt Capital One eine schwerwiegende Datenschutzverletzung, die die persönlichen Daten von über 100 Millionen Kunden betraf 12. Obwohl die Hauptursache dieses Angriffs AWS-Konfigurationsfehler waren, waren auch Containersicherheitsprobleme beteiligt, die Ihrer beschriebenen Situation ähneln:

1. Container-Berechtigungsprobleme: Der Angreifer nutzte eine Schwachstelle in einer Web Application Firewall (WAF) aus, die in einem Container lief, aber über übermäßige Berechtigungen verfügte.
2. Unzureichende Netzwerkisolation: Der Angreifer konnte von dem kompromittierten Container aus auf andere AWS-Ressourcen zugreifen, was auf unzureichende Netzwerkisolationsmaßnahmen hinweist.
3. Offenlegung sensibler Daten: Aufgrund von Konfigurationsfehlern konnte der Angreifer auf eine große Menge sensibler Kundendaten zugreifen und diese stehlen.
4. Fehler bei der Sicherheitskonfiguration: Die Grundursache des gesamten Vorfalls war die Anhäufung mehrerer Fehler bei der Sicherheitskonfiguration, einschließlich Problemen bei der Container- und Cloud-Dienstkonfiguration.

Dieser Vorfall führte zu erheblichen finanziellen Verlusten und Reputationsschäden für Capital One. Es wird berichtet, dass das Unternehmen aufgrund dieses Vorfalls mit Geldstrafen von bis zu 150 Millionen US-Dollar sowie einer langfristigen Vertrauenskrise konfrontiert war. Dieser Fall unterstreicht die Bedeutung der Sicherheitskonfiguration in Container- und Cloud-Umgebungen, insbesondere im Berechtigungsmanagement, der Netzwerkisolation und dem Schutz sensibler Daten. Er erinnert uns daran, dass selbst scheinbar geringfügige Konfigurationsfehler von Angreifern ausgenutzt werden können, was zu katastrophalen Folgen führt.

IV. Fazit und Empfehlungen​

Docker Compose in Kombination mit Ubuntu ist eine bequeme Möglichkeit, Container-Anwendungen schnell bereitzustellen, aber Sicherheit muss während des gesamten Prozesses integriert werden:

• Container-Berechtigungen und Netzwerkisolation streng kontrollieren.
• Lecks sensibler Daten vermeiden.
• Regelmäßige Sicherheitsscans und Updates.
• Es wird empfohlen, bei zunehmender Unternehmensgröße auf fortschrittliche Orchestrierungssysteme wie Kubernetes zu migrieren, um eine stärkere Sicherheitsgarantie zu erhalten.

Sicherheit ist eine kontinuierliche Praxis ohne Endpunkt. Ich hoffe, dieser Artikel hilft Ihnen, Ihre Docker Compose + Ubuntu Bereitstellungsumgebung besser zu schützen.