Secret-Bereitstellung
Das Laden von Secrets ist hinter einem einzigen SECRET_BACKEND-Schalter
vereinheitlicht. Diese Seite erklärt das Modell; die Liste der Variablen findest
du unter Umgebungsvariablen.
Der Backend-Schalter
Abschnitt betitelt „Der Backend-Schalter“SECRET_BACKEND ist einer der folgenden Werte:
env— Secrets stammen ausschließlich aus der Umgebung. SupaCloud kontaktiert niemals einen Vault.openbao— Secrets werden beim Start aus OpenBao geladen, wobei die Umgebung als Override dient. Ein erforderliches Secret, das in beiden — Vault und Umgebung — fehlt, ist beim Start fatal.
Wenn SECRET_BACKEND nicht gesetzt ist, erkennt SupaCloud das Backend
automatisch: Es wählt openbao, wenn eine Vault-Authentifizierung vorhanden
ist (ein VAULT_TOKEN oder eine AppRole-ID + ein AppRole-Secret), andernfalls
env.
Ein einziger App-Secret-Pfad
Abschnitt betitelt „Ein einziger App-Secret-Pfad“Im OpenBao-Modus liegen die Anwendungs-Secrets unter einem einzigen KV-v2-Pfad,
supacloud/app, indiziert nach dem Namen der Umgebungsvariable. Sie werden
beim Start einmalig geladen und füllen Felder, die noch leer sind — zum Beispiel
das JWT-Secret, das OIDC-Client-Secret und Bot-Tokens.
Wo der Schlüssel liegt
Abschnitt betitelt „Wo der Schlüssel liegt“Der Schlüssel zur Verschlüsselung von Anmeldedaten wird in einem write-once-Halter im Prozess gehalten, der beim Start nur dann befüllt wird, wenn der Schlüssel aus dem Vault stammt — so gelangt ein aus dem Vault stammender Schlüssel niemals in die Prozessumgebung. Ein vom Betreiber bereitgestellter Schlüssel verbleibt in der Umgebung, in der er platziert wurde.
Ein einziger Schalter hält kleine selbst gehostete Deployments einfach (env,
kein Vault) und ermöglicht es größeren Deployments zugleich, Secrets ohne
Codeänderungen in OpenBao zu zentralisieren — und verschiebt die
Produktions-Validierungsprüfungen hinter die Hydration, sodass ein vom Vault
bereitgestelltes Secret sie erfüllt. Dies ist Gegenstand von
ADR 0036.