Zum Inhalt springen
Farbschema wählenSprache wählen

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.

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.

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.

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.