In Docker Compose werden häufig Umgebungsvariablen über .env-Dateien gesetzt. Für einfache Konfigurationen ist das ausreichend, jedoch birgt die Nutzung von .env für sensitive Daten erhebliche Sicherheitsrisiken. Passwörter, API-Keys oder Zertifikate sollten nie unverschlüsselt in Versionskontrollsystemen oder auf dem Host liegen. Dieser Artikel zeigt, warum .env nicht ausreicht und welche sicheren Alternativen in Compose verfügbar sind.

1. Die Grenzen von .env Dateien

Die .env-Datei ist für die Konfiguration von Compose-Services gedacht, wird aber oft falsch verwendet:

• Wird oft ins Git-Repository eingecheckt
• Unverschlüsselt auf dem Host gespeichert
• Kann in Logs oder Container-Umgebungen sichtbar werden

Beispiel: .env Datei

DB_USER=admin
DB_PASSWORD=geheim
API_KEY=abcdef123456

Jeder mit Zugriff auf das Repository oder den Server kann sensible Daten auslesen.

2. Docker Secrets: Der sichere Standard

Docker Compose unterstützt seit Version 3 Docker Secrets, die speziell für sensible Daten entwickelt wurden. Secrets werden verschlüsselt gespeichert und nur für Container zugänglich gemacht, die sie benötigen.

Secret erstellen und nutzen

# Secret erstellen
echo "geheimes_passwort" | docker secret create db_password -
docker-compose.yml Beispiel
version: '3.8'

services:

db:

image: postgres:15

secrets:

- db_password

secrets:

db_password:

external: true

Im Container steht das Secret dann in /run/secrets/db_password zur Verfügung, ohne dass es in der Shell-Umgebung sichtbar wird.

3. Vergleich: .env vs. Secrets

• .env: Einfach, aber unsicher für sensible Daten, global sichtbar im Container
• Secrets: Verschlüsselt, nur für die definierten Services zugänglich, nicht in Logs oder Environment sichtbar

4. Environment-Variablen nur für Konfiguration

Umgebungsvariablen sind weiterhin sinnvoll für nicht-sensitive Konfigurationen wie Ports, Feature Flags oder Pfade:

version: '3.8'
services:
  web:
    image: nginx:alpine
    environment:
      - PORT=8080
      - LOG_LEVEL=info

Für sensitive Werte sollten Environment-Variablen jedoch niemals Klartext enthalten.

5. Kombination von .env und Secrets

Eine gängige Praxis ist, .env Dateien für allgemeine Konfiguration zu nutzen und Secrets für sensible Werte zu verwenden. Dies trennt Konfiguration von sensiblen Daten.

version: '3.8'
services:
  app:
    image: myapp:latest
    environment:
      - APP_ENV=production
    secrets:
      - db_password
secrets:
  db_password:
    external: true

6. Secrets in CI/CD Pipelines

Auch in CI/CD Umgebungen sollten Secrets nicht als plain text übergeben werden. Viele Tools wie GitHub Actions oder GitLab CI unterstützen geheime Variablen, die in Compose Deployments übergeben werden können:

# GitHub Actions Beispiel
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Deploy Compose
        run: |
          echo "${{ secrets.DB_PASSWORD }}" | docker secret create db_password -
          docker stack deploy -c docker-compose.yml mystack

Die Secrets werden temporär erstellt und bleiben nicht im Repository oder in Logs erhalten.

7. Best Practices für Compose Secrets

• Nur benötigte Services auf Secrets zugreifen lassen
• Secrets niemals in .env Dateien speichern
• Externe Secrets verwalten und versionieren (z. B. Vault, AWS Secrets Manager)
• Container Logs auf unbefugte Ausgabe sensibler Daten prüfen
• CI/CD Systeme nutzen, um Secrets sicher zu injecten

8. Alternative Tools für Secret Management

Für komplexere Setups lohnt sich die Integration spezialisierter Secret Manager:

• HashiCorp Vault: Dynamische Geheimnisse, Token-basiert, Audit-Log
• AWS Secrets Manager / Parameter Store: Cloud-basiert, IAM-gesteuert
• Sops: Verschlüsselte YAML/JSON Dateien für Compose

9. Fazit für sichere Compose Setups

Die Nutzung von .env Dateien für Secrets ist unsicher. Docker Secrets oder externe Secret Manager bieten eine verschlüsselte, kontrollierte Möglichkeit, sensible Daten in Compose Deployments zu verwenden. Für jede Umgebung – lokal, staging oder Produktion – sollten Secrets konsequent getrennt und nur dort verfügbar sein, wo sie benötigt werden.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.