March 8, 2026

Configs vs. Secrets: Trennung von Konfiguration und Credentials

In Docker Compose und Swarm-Umgebungen ist es essenziell, zwischen Konfigurationsdaten und sensiblen Informationen wie Passwörtern oder Tokens zu unterscheiden. Während Konfigurationsdateien (Configs) für Applikationseinstellungen genutzt werden, sind Secrets speziell für Credentials und andere vertrauliche Daten gedacht. Eine klare Trennung erhöht die Sicherheit, vereinfacht Deployments und erleichtert Compliance-Anforderungen.

Table of Contents

1. Grundlagen: Configs und Secrets

Docker unterscheidet zwei Haupttypen von Daten, die in Containern bereitgestellt werden können:

Configs: Statische Konfigurationsdateien, die für die Anwendung benötigt werden (z. B. nginx.conf, appsettings.json).
Secrets: Sensible Daten wie Passwörter, API-Keys oder Zertifikate, die verschlüsselt gespeichert und nur den benötigten Services verfügbar gemacht werden.

Wichtiger Unterschied

Configs werden standardmäßig im Klartext gespeichert, während Secrets verschlüsselt abgelegt und nur für den Container im Laufzeitpfad /run/secrets/ zugänglich sind. Dies verhindert unbefugten Zugriff.

2. Configs in Compose

Configs eignen sich für Einstellungen, die für alle Umgebungen relevant sind und nicht geheim gehalten werden müssen. Sie werden über Compose definiert und in den Service eingebunden.

version: '3.8'
services:
  web:
    image: nginx:alpine
    configs:
      - source: nginx_config
        target: /etc/nginx/nginx.conf

configs:
  nginx_config:
    file: ./nginx.conf

Der Container erhält die Config automatisch unter dem angegebenen Pfad. Änderungen an der Config können über ein erneutes Deploy direkt übernommen werden.

3. Secrets in Compose

Secrets werden für sensible Daten eingesetzt. Sie werden verschlüsselt gespeichert und nur dem definierten Service zugänglich gemacht.

version: '3.8'
services:
  db:
    image: postgres:15
    secrets:
      - db_password

secrets:
  db_password:
    file: ./db_password.txt

Im Container erscheint das Secret unter /run/secrets/db_password und wird nicht als Umgebungsvariable exponiert.

4. Best Practices für die Trennung

Configs für nicht-sensible Einstellungen verwenden, die Versionskontrolle vertragen.
Secrets für Passwörter, Tokens und Zertifikate einsetzen.
Nie Secrets in .env Dateien oder Configs ablegen.
Nur Services Zugriff auf die Secrets geben, die sie wirklich benötigen.
Secrets aus CI/CD-Pipelines sicher injizieren (z. B. GitHub Actions Secrets, GitLab CI Variables).

5. Zugriff und Mounting

Configs und Secrets werden unterschiedlich in den Container gemountet:

Configs: Können an beliebige Pfade gemountet werden, standardmäßig im readonly Modus.
Secrets: Immer readonly, standardmäßig im Laufzeitverzeichnis /run/secrets/.

services:
  app:
    configs:
      - source: app_config
        target: /app/config.yaml
    secrets:
      - db_password

6. Versionierung und Updates

Durch die Trennung lassen sich Configs und Secrets unabhängig voneinander versionieren und aktualisieren. Eine neue Config-Version kann ausgerollt werden, ohne die Secrets zu ändern, und umgekehrt.

7. Sicherheitsaspekte

Secrets niemals im Repository speichern.
Nur für bestimmte Services verfügbar machen.
Im CI/CD sicher über Umgebungsvariablen oder Secret Manager injizieren.
Regelmäßig Audit-Logs prüfen, um unbefugten Zugriff zu erkennen.
Wenn möglich, Secrets mit Ablaufdatum oder Rotation versehen.

8. Integration mit Secret Management Systemen

Für komplexe Setups lohnt sich die Integration mit externen Secret Managern:

HashiCorp Vault: Token-basiert, dynamische Secrets, Audit-Logging.
AWS Secrets Manager: IAM-gesteuert, Versionierung, automatische Rotation.
Sops / Mozilla SOPS: Verschlüsselte YAML/JSON Dateien, kompatibel mit GitOps.

9. Fazit

Die konsequente Trennung von Konfiguration und Credentials in Compose verbessert Sicherheit und Wartbarkeit. Configs dienen der Anwendungskonfiguration, Secrets schützen sensible Daten. Für produktive Deployments sollte diese Trennung strikt eingehalten und mit CI/CD- und Secret-Management-Systemen kombiniert 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.