Secrets Management für kleine Self-Hosted-Umgebungen

In kleinen Self-Hosted-Umgebungen liegen sensible Werte erstaunlich oft an den falschen Orten: in Compose-Dateien, in Shell-History, in Screenshots, in Notizen oder direkt im Git-Repository. Genau deshalb lohnt sich ein bewusstes Secrets Management auch dann, wenn du noch kein grosses Team und keine riesige Plattform betreibst.

In dieser Anleitung schauen wir uns an, wie du Secrets in kleinen Self-Hosted-Umgebungen sinnvoll verwaltest, welche Stufen praxistauglich sind, wann eine einfache .env-Datei reicht und wo Docker-Compose-Secrets oder ein Passwort-Manager die sauberere Lösung sind.

1. Was überhaupt ein Secret ist

Ein Secret ist jeder Wert, der nicht öffentlich oder breit sichtbar herumliegen sollte. Typische Beispiele:

• Datenbank-Passwörter
• API-Tokens
• SMTP-Zugangsdaten
• JWT- oder Session-Secrets
• Backup-Passwörter
• SSH-Keys oder private Zertifikatsdateien

Wichtig ist nicht nur, ob ein Wert geheim ist, sondern auch wie kritisch sein Verlust oder Missbrauch wäre.

2. Die Grundfrage: Wie klein ist das Setup wirklich?

Nicht jede Umgebung braucht sofort ein grosses Secret-Management-System. Für viele kleine Self-Hosted-Setups reicht eine gute, disziplinierte Basis völlig aus.

Ein praktikables Reifestufenmodell sieht so aus:

• Stufe 1: saubere .env-Dateien plus Passwort-Manager
• Stufe 2: Secrets zusätzlich als Dateien oder Docker-Compose-Secrets strukturieren
• Stufe 3: bei grösserem Team oder höherem Risiko dediziertes Secret-Management prüfen

Viele kleine Umgebungen scheitern nicht an fehlender Enterprise-Software, sondern an fehlender Ordnung.

3. Die grössten Fehler zuerst vermeiden

• Secrets direkt in Compose-Dateien schreiben
• .env-Dateien ins Git-Repository committen
• denselben Secret-Wert in vielen Diensten wiederverwenden
• keinen Überblick haben, welche Secrets überhaupt existieren
• kritische Passwörter nur auf dem Server selbst speichern

Wenn du nur diese Fehler sauber vermeidest, hast du bereits einen sehr grossen Teil des Problems entschärft.

4. Die einfache und oft richtige Basis: .env plus Passwort-Manager

Für viele Compose-basierte Setups ist eine lokale .env-Datei pro Stack ein guter Startpunkt. Beispiel:

DB_PASSWORD=ein-langes-zufaelliges-passwort
SMTP_PASSWORD=noch-ein-zufaelliger-wert
AUTHENTIK_SECRET_KEY=ein-sehr-langer-geheimer-string

Wichtig ist dazu:

• die Datei nie committen
• Dateirechte sauber halten
• zusätzlich alle produktiven Secrets in einem Passwort-Manager oder sicheren Tresor dokumentieren

Damit hast du sowohl eine lokale Laufzeitbasis als auch eine vom Server getrennte sichere Referenz.

5. Docker Compose Secrets sinnvoll einordnen

Die offizielle Docker-Dokumentation beschreibt im Compose-Format Secrets als sensiblen Datentyp, der Diensten explizit zugewiesen wird. Die Quelle kann dabei eine Datei oder eine Host-Umgebungsvariable sein.

Ein einfaches Beispiel sieht so aus:

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  app:
    image: ghcr.io/example/app:latest
    secrets:
      - db_password

Im Container landet das Secret typischerweise unter /run/secrets/.... Das ist oft sauberer als ein Passwort direkt als normale Umgebungsvariable zu übergeben, sofern die Anwendung dieses Muster unterstützt.

Wichtig ist aber auch: Nicht jede Anwendung kann Secrets-Dateien direkt lesen. Dann braucht es weiterhin Variablen oder ein vorgeschaltetes Startskript.

6. Wann Dateien für Secrets sinnvoll sind

Gerade für folgende Werte sind separate Dateien oft angenehm:

• lange Tokens
• private Schlüssel
• Zertifikate
• Passwörter für Anwendungen, die Dateipfade unterstützen

Eine mögliche Struktur:

~/stacks/authentik/
├── compose.yaml
├── .env
├── secrets/
│   ├── smtp_password.txt
│   └── db_password.txt
└── data/

Damit wird schneller sichtbar, was Konfiguration, was Secret und was persistente Daten sind.

7. Rotation und Trennung mitdenken

Gute Secrets-Verwaltung bedeutet auch:

• nicht überall denselben Passwortwert verwenden
• produktive und Test-Zugangsdaten klar trennen
• wichtige Tokens rotierbar halten
• bei Personalwechsel oder Geräteverlust gezielt widerrufen können

Gerade bei SMTP, API-Diensten, Backup-Systemen oder Cloud-Zugängen ist Rotation viel realistischer, wenn du die Secrets überhaupt sauber dokumentiert hast.

8. Ein kleines Inventar ist Gold wert

Ich würde für kleine Umgebungen immer ein minimales Secret-Inventar pflegen. Darin steht nicht der geheime Wert selbst in Klartext, sondern:

• Name des Secrets
• wo es verwendet wird
• wo die sichere Ablage liegt
• wer Zugriff braucht
• wann es zuletzt geändert wurde

Schon diese kleine Übersicht verhindert, dass später niemand mehr weiss, welche Tokens eigentlich produktiv relevant sind.

9. Was ich für kleine Self-Hosted-Umgebungen konkret empfehlen würde

• pro Stack eigene .env-Datei
• kritische Secrets zusätzlich im Passwort-Manager dokumentieren
• wo möglich Datei-basierte Secrets oder Compose-Secrets nutzen
• keine Secrets in Git, Tickets oder Screenshots
• produktive und Test-Umgebung sauber trennen

Das ist keine Hochglanz-Enterprise-Lösung, aber für viele kleinere Server bereits sehr ordentlich und professionell.

10. Wann ein grösseres Secret-System sinnvoll wird

Spätestens wenn mehrere Personen regelmässig deployen, wenn viele Dienste stark miteinander integriert sind oder wenn Compliance- und Revisionsanforderungen steigen, lohnt sich ein dedizierteres Secret-System eher.

Für viele kleine Setups ist der Sprung dorthin aber erst sinnvoll, wenn die einfache Grundordnung bereits sauber funktioniert. Sonst baust du nur mehr Technik auf ein unaufgeräumtes Fundament.

11. Typische Stolpersteine

• die Anwendung unterstützt Datei-Secrets nicht, aber man plant damit
• Secrets liegen zwar in Dateien, diese sind aber ungesichert oder unklar benannt
• Passwort-Manager und Serverstand widersprechen sich
• Backups enthalten Secrets, aber niemand weiss, wie diese im Restore sicher behandelt werden
• die Rotation eines Secrets wird vergessen, weil Abhängigkeiten nicht dokumentiert sind

Auch hier hilft weniger Magie als klare Struktur.

12. Fazit

Secrets Management für kleine Self-Hosted-Umgebungen muss nicht kompliziert sein. Für viele Setups reicht eine disziplinierte Kombination aus .env-Dateien, sauberer Dateistruktur, Passwort-Manager und wo passend Docker-Compose-Secrets vollkommen aus.

Entscheidend ist, dass du Geheimnisse bewusst behandelst, dokumentierst und trennst. Genau das macht aus improvisierten Passwörtern eine wartbare Sicherheitsbasis.

Tipp:
Wenn du heute anfangen willst, dann prüfe zuerst deine bestehenden Compose-Dateien auf fest eingetragene Passwörter und ziehe diese systematisch in .env-Dateien oder Secret-Dateien um. Das ist oft der wichtigste erste Schritt.