Konfiguration, Passwörter und Vault

01

1. Was gehört in die .env-Datei?

• Dienst-URL, Modusauswahl, Zeitzone, Datenbanknamen und andere nicht geheime Parameter.
• Vollständige Bildreferenz mit Digest, falls es sich bei der Datei um eine Release-kontrollierte Komponente handelt.
• Funktionsumschaltungen, die von der Version explizit unterstützt und validiert werden.
• Speichern Sie niemals Ihr tatsächliches Passwort, Ihren privaten Schlüssel, Ihr Zugriffstoken, Ihr Clientgeheimnis oder Ihre Registry-Anmeldedaten in einer Git-versionierten Datei.

02

2. Empfohlenes Layout auf dem Host

/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Hinweis: Die .env-Datei ist kein Geheimnismanager. Die Anmeldung an der Registry erfolgt über einen Anmeldeinformationshelfer oder eine verwaltete Docker-Anmeldung mit einem Bereitstellungstoken; das Compose-Geheimnis selbst autorisiert keine Image-Downloads. Sensible Werte bleiben außerhalb von Git, mit minimalen Berechtigungen und der beschriebenen Rotation.

03

3. Docker-Secrets-Variante

Zielstandard – Dateinamen und Unterstützung für _FILE-Variablen müssen im Manifest einer bestimmten Version bestätigt werden.

1. DERS wird eine Liste der erwarteten Geheimnisse und eine bestätigte Methode zu deren Abruf bereitstellen.
2. Der Administrator erstellt jedes Geheimnis außerhalb des Bezahlvorgangs und legt Besitzverhältnisse und Berechtigungen fest.
3. Compose fügt ein Geheimnis nur dem Dienst hinzu, der es benötigt.
4. Die Anwendung darf den Wert weder beim Start noch bei einem Validierungsfehler ausgeben.
5. Die Rotation wird gemäß dem Service-Runbook durchgeführt und durch eine neue Anmeldung oder Verbindung verifiziert.

04

4. HashiCorp Vault-Variante

Zielstandard – die Methode der Authentifizierung, der Lease-Verlängerung und des Neuladens muss vom jeweiligen Dienst und Release bestätigt werden.

1. Der Dienst bzw. Vault Agent authentifiziert sich mit einer Maschinenidentität, die an eine bestimmte Umgebung gebunden ist; er verwendet kein gemeinsam genutztes persönliches Token.
2. Die Richtlinie erlaubt nur die für einen bestimmten Dienst erforderlichen Pfade und Operationen.
3. Der Vault-Agent schreibt das Geheimnis in eine tmpfs-Datei oder stellt es der Anwendung über einen unterstützten Mechanismus zur Verfügung.
4. Die Wiederherstellung kurzfristiger Daten löst einen unterstützten Neuladevorgang oder einen kontrollierten Neustart aus.
5. Vault-Audit, Anwendungs-Audit und Betriebsprotokolle werden korreliert, ohne dass der geheime Wert selbst geschrieben wird.

05

5. Reihenfolge des Ladens und der Validierung

1. Es werden nur die in der Version enthaltenen Standardwerte für nicht-geheime Optionen geladen.
2. Lade release.env und site.env.
3. Geheimnisse werden aus Dateien oder dem Vault entnommen; der geheime Wert hat niemals einen sicheren, universellen Standardwert.
4. Wenn ein Pflichtwert fehlt, beenden Sie die Eingabe, bevor Sie mit dem Parameternamen und nicht mit dessen Inhalt beginnen.
5. Gibt eine anonymisierte Konfigurationszusammenfassung aus: Modus, Ziel-URL, Version und geheime Quelle, jedoch nicht das Geheimnis selbst.
6. Führen Sie Verbindungstests durch und akzeptieren Sie erst dann die Betriebsanforderungen.

06

6. Rotation ohne manuelles Überschreiben

• Jedes Geheimnis hat einen Besitzer, eine Quelle, ein Ablaufdatum und eine Wiederherstellungsmethode.
• Die Daten im Dynamic Vault unterliegen einem Mietvertrag mit automatischer Verlängerung.
• OIDC-Client-Secrets werden durch Überschreiben der alten und neuen Werte geändert, sofern dies vom IdP und der Anwendung unterstützt wird.
• Die Notfallrotation hat ein eigenes Verfahren und ist unabhängig von der Person, die die Installation ursprünglich durchgeführt hat.
• Nach der Rotation werden die Servicefunktion und das Audit überprüft; der alte Wert wird erst nach Bestätigung ungültig.