Self-hosted Secrets Manager im Vergleich

Was ein selbst gehosteter Secrets Manager leistet, was ein Passwortmanager nicht leistet

Ein selbst gehosteter Secrets Manager stellt Prozessen Zugangsdaten bereit. Ein Passwortmanager stellt Zugangsdaten Menschen bereit. Alles Weitere ergibt sich aus diesem einen Unterschied. Einen Passwortmanager entsperrt ein anwesender und aufmerksamer Mensch. Ein Secrets Manager muss Ihrer Anwendung um 03:00 ein Datenbankpasswort bereitstellen, wenn niemand wach ist.

Die Fehlerbilder unterscheiden sich auf eine wichtige Weise. Ein gesperrter Passwortmanager ist eine Unannehmlichkeit: Sie geben das Master-Passwort erneut ein. Ein versiegelter Secrets Manager ist ein Ausfall: Jeder Dienst, der während der Versiegelung neu startet, wird ohne Zugangsdaten gestartet und bleibt inaktiv. Vaultwarden als eigenen Passwortmanager betreiben löst das menschliche Problem gut. Das Maschinenproblem löst es nicht, und dafür wurde es auch nie entwickelt.

Die realistischen Optionen für einen Server fallen in zwei Gruppen. OpenBao und Infisical sind Dienste: eine API, eine Datenbank, TLS (Transport Layer Security), ein Anmeldeschritt und ein Prozess, den Sie nun dauerhaft am Laufen halten müssen. SOPS mit age, systemd credentials und Docker secrets sind Dateien: im Ruhezustand verschlüsselt, durch bereits laufende Software entschlüsselt und ohne zusätzliche Komponente, die überwacht werden muss.

Die ehrliche Antwort gleich vorweg: Für einen einzelnen Server mit einer oder zwei Personen sind dateibasierte Optionen normalerweise die richtige Wahl. Ein OpenBao, den niemand ordnungsgemäß entsperrt und für den niemand Zugangsdaten regelmäßig erneuert, ist schlechter als eine Env-Datei mit mode 600. Er fügt eine weitere bewegliche Komponente und ein Backup hinzu, das Sie wahrscheinlich falsch erstellen. Eine Erneuerung von Zugangsdaten erhalten Sie dadurch nicht, wenn Sie sie nicht ohnehin bereits manuell durchführen.

Ist eine Env-Datei mit dem Modus 600 ausreichend?

Oft ja. Sie schützt davor, dass ein anderer Benutzer auf dem System Ihr Datenbankpasswort liest. Unix-Dateiberechtigungen verhindern das. Sie greifen bereits, bevor das Netzwerk verfügbar ist.

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

Prüfen Sie die Datei von beiden Seiten:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

Der erste Befehl gibt die Datei aus. Der zweite gibt cat: /etc/myapp/env: Permission denied aus, weil nobody nicht zur Gruppe myapp gehört und die Datei keine Berechtigungen für andere Benutzer besitzt. Das ist das gesamte Sicherheitsmodell. Es ist ein wirksames Sicherheitsmodell.

Das eigentliche Leck entsteht im nächsten Schritt. Eine systemd-Unit mit EnvironmentFile= übernimmt diese Werte in die Prozessumgebung. Die Prozessumgebung ist lesbar.

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp

sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

Damit werden Ihre Geheimnisse im Klartext ausgegeben, weil /proc/<pid>/environ für root und für den Benutzer lesbar ist, unter dem der Prozess ausgeführt wird. Ein Crash-Reporter, der die Umgebung an einen Bericht anhängt, kann dieselben Daten sehen. Das gilt auch für jedes Tool, das unter demselben Benutzerkonto ausgeführt wird. Deshalb beginnt das Fernhalten von Geheimnissen aus AI-Agenten damit, sie aus der Umgebung zu entfernen. Kombinieren Sie die Datei mit einem dedizierten Dienstbenutzer mit niedrigen Berechtigungen, damit „der Benutzer, unter dem der Prozess ausgeführt wird“ nicht root ist.

SOPS mit age: Verschlüsselte Secrets, die Sie in Git committen können

SOPS (secrets operations) verschlüsselt die Werte in einer YAML- oder JSON-Datei und lässt die Schlüssel im Klartext stehen. age ist ein kleines Verschlüsselungsprogramm, das Ihnen ein Schlüsselpaar ohne Schlüsselserver bereitstellt. Zusammen können Sie damit secrets.enc.yaml neben Ihrem Code committen, während git diff weiterhin zeigt, welche Einstellung geändert wurde, ohne den neuen Wert offenzulegen.

age ist in Ubuntu 24.04 paketiert. SOPS ist dort nicht enthalten. Laden Sie daher .deb von der Release-Seite herunter. Version 3.13.3 war im August 2026 aktuell.

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

Generieren Sie ein Schlüsselpaar. age-keygen schreibt den privaten Schlüssel in die Datei und gibt den öffentlichen Schlüssel aus. Sie sehen daher eine Zeile, die mit Public key: age1... beginnt.

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

Legen Sie den öffentlichen Schlüssel in .sops.yaml im Stammverzeichnis des Repositorys ab. Dadurch müssen Sie den Empfänger nicht bei jedem Aufruf auf der Befehlszeile angeben.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

Eine Regel ohne path_regex trifft auf alles zu. Das ist zunächst das gewünschte Verhalten. Wenn Sie später eine Regel hinzufügen, muss sie auf die Datei passen, die Sie an sops übergeben. Regeln werden anhand des Eingabepfads geprüft, nicht anhand der Datei, in die Sie die Ausgabe umleiten.

Übergeben Sie die Werte zur Laufzeit genau einem Prozess und keinem anderen:

sops exec-env secrets.enc.yaml './myapp'

sops exec-env entschlüsselt die Werte im Arbeitsspeicher und setzt sie in der Umgebung des Kindprozesses. Dadurch wird kein Klartext auf die Festplatte geschrieben. Die Einschränkung für Umgebungsvariablen aus dem vorherigen Abschnitt gilt für diesen Kindprozess weiterhin.

Hier führen zwei Punkte häufig zu Problemen. Der Fehler Failed to get the data key required to decrypt the SOPS file unter systemd bedeutet fast immer, dass SOPS im falschen Home-Verzeichnis gesucht hat, weil eine Unit Ihr HOME nicht übernimmt. Setzen Sie den Pfad mit Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt explizit in der Unit. Außerdem verschlüsselt das Bearbeiten von .sops.yaml keine bereits vorhandenen Dateien erneut. Das Hinzufügen des öffentlichen Schlüssels eines Kollegen gilt nur für neue Dateien. Führen Sie daher sops updatekeys secrets.enc.yaml für jede vorhandene Datei aus. Wenn Ihre Konfiguration bereits über Ansible läuft, erreichen Sie mit der Verschlüsselung derselben Werte mit Ansible Vault dasselbe Ziel ohne ein zweites Tool.

systemd-Anmeldeinformationen: Geheimnisse, die nie die Umgebung erreichen

Ubuntu 24.04 enthält systemd 255. Eine Installation ist daher nicht erforderlich. systemd-creds verschlüsselt ein Geheimnis auf dem Host, und systemd entschlüsselt es in ein privates Verzeichnis, auf das nur der betreffende Dienst zugreifen kann.

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred

[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

Der Dienst liest den Wert aus einer Datei namens db_password innerhalb des durch $CREDENTIALS_DIRECTORY bezeichneten Verzeichnisses. Der Wert befindet sich nicht in der Umgebung. Daher zeigt /proc/<pid>/environ nichts Verwertbares an, und der Klartext wird nie im Root-Dateisystem abgelegt.

Prüfen Sie, ob die Datei entschlüsselt werden kann, bevor Sie eine Unit darauf verweisen lassen:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

Ermitteln Sie, mit welchem Schlüssel die Datei verschlüsselt wurde. Davon hängt ab, ob Ihr Backup im Notfall verwendbar ist. Die Standardoption --with-key=auto verwendet den TPM2-Chip (Trusted Platform Module Version 2), sofern ein solcher vorhanden und verwendbar ist. Andernfalls wird der Hostschlüssel verwendet. Die meisten VPS-Instanzen verfügen über kein TPM2.

systemd-analyze has-tpm2

no bedeutet, dass der Hostschlüssel verwendet wurde. Dieser Schlüssel befindet sich in /var/lib/systemd/credential.secret und ist nur für root lesbar. Wenn Sie db_password.cred auf einem frischen VPS wiederherstellen, auf dem diese Datei fehlt, kann nichts entschlüsselt werden. Kopieren Sie credential.secret in dasselbe Backup oder bewahren Sie den Klartext an einem Ort auf, auf den Sie weiterhin zugreifen können.

Docker-Secrets: Dateien unter /run/secrets

Compose liest eine Datei vom Host und bindet sie im Container unter /run/secrets/<name> ein.

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt

docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

Der erste Befehl gibt das Secret aus. Der zweite gibt nur DB_PASSWORD_FILE=/run/secrets/db_password aus. Genau das ist der Zweck: Der Wert befindet sich nie in der Container-Umgebung und erscheint daher nicht in der Ausgabe von docker inspect. Viele offizielle Images erwarten diese Struktur bereits. Das Postgres-Image liest POSTGRES_PASSWORD_FILE genau auf diese Weise.

Machen Sie sich klar, was dies bedeutet. Außerhalb des Swarm-Modus gibt es auf keiner Ebene eine Verschlüsselung: ./db_password.txt ist eine Klartextdatei auf dem Host. Geschützt wird sie nur durch ihre Dateirechte und ihren Besitzer. Setzen Sie beides selbst, weil Compose eine weltweit lesbare Datei ohne Warnung einbindet. Eine ausführlichere Gegenüberstellung der Vor- und Nachteile gegenüber der einfachen Variante mit env_file finden Sie im Leitfaden zu Compose-Umgebungsdateien und Secrets.

Was OpenBao und Vault im Betrieb wirklich kosten

OpenBao ist der Fork von HashiCorp Vault durch die Linux Foundation. Er entstand, nachdem HashiCorp Vault 2023 unter der Business Source License neu lizenziert hatte. OpenBao bleibt unter der MPL 2.0 (Mozilla Public License). Release 2.6.2 war im August 2026 aktuell. Fast alles Folgende gilt auch für Vault, weil der Fork dieselbe Befehlsschnittstelle beibehalten hat.

docker pull docker.io/openbao/openbao

Debian- und Ubuntu-Pakete finden Sie auf der OpenBao-Downloadseite, wenn Sie Upgrades lieber mit apt verwalten möchten. Der Server benötigt eine Konfigurationsdatei mit einem Listener und einem Storage-Backend:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

Starten Sie ihn anschließend einmal:

bao operator init

Standardmäßig wird der Root-Schlüssel in 5 Anteile aufgeteilt. Zum Aufheben der Versiegelung sind 3 davon erforderlich. Dafür stehen die Flags -key-shares und -key-threshold. OpenBao gibt die Anteile und das anfängliche Root-Token einmalig aus. Danach werden sie nicht erneut ausgegeben.

Der wichtigste Punkt wird in den meisten Vergleichen ausgelassen. Ein neu gestarteter Server ist versiegelt. OpenBao hält den Root-Schlüssel nur im Arbeitsspeicher. Nach einem Neustart kann OpenBao daher seinen eigenen Storage nicht entschlüsseln, bis jemand die erforderliche Anzahl an Anteilen bereitstellt. Ein Kernel-Update oder eine Beendigung wegen Speichermangels führt deshalb zu einem versiegelten Server. Die Anwendungen können sich dann nicht anmelden.

Auf einem VPS, den eine einzelne Person betreibt, schützt die Aufteilung mit Shamir nichts, weil alle 5 Anteile letztlich im selben Passwort-Manager derselben Person landen. Auto-Unseal verschiebt den Schlüssel auf ein vertrauenswürdiges Gerät oder einen vertrauenswürdigen Dienst. In einer großen Cloud bedeutet das meist einen verwalteten Schlüsseldienst. Auf Ihrem VPS ist es dagegen normalerweise eine Schlüsseldatei auf derselben Festplatte wie die Daten, die sie schützt. Das ist eine tatsächliche Verringerung der Sicherheit. Im Gegenzug startet der Server nach einem Reboot selbstständig wieder. Treffen Sie diese Abwägung bewusst und dokumentieren Sie, wofür Sie sich entschieden haben.

Infisical: eine Benutzeroberfläche, eine Datenbank und ein Master-Key, den Sie weiterhin besitzen

Infisical ist eine Secrets-Plattform mit Weboberfläche, Projekten, Umgebungen und einer benutzerbezogenen Zugriffskontrolle. Das Self-Hosting mit Compose ist kurz:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

Bearbeiten Sie .env vor dem letzten Befehl. Zwei Werte müssen von Ihnen stammen. Einer davon darf danach niemals geändert werden:

openssl rand -hex 16
openssl rand -base64 32

Der erste Wert ist ENCRYPTION_KEY, eine hexadezimale Zeichenfolge mit 16 Byte. Mit diesem Schlüssel werden Ihre Secrets innerhalb von PostgreSQL verschlüsselt. Wenn Sie ihn verlieren, wird aus einem vollständigen Datenbank-Backup nur ein Stapel Chiffretext. Wenn Sie ihn bei einer laufenden Instanz ändern, lassen sich vorhandene Secrets nicht mehr entschlüsseln. Der zweite Wert ist AUTH_SECRET, eine Base64-Zeichenfolge mit 32 Byte für Sitzungen. SITE_URL muss die absolute URL sein, unter der Sie die Anwendung tatsächlich erreichen, einschließlich Protokoll. Andernfalls schlägt die Anmeldeweiterleitung fehl.

Infisical eignet sich besser als OpenBao, wenn Sie tatsächlich Benutzer benötigen: eine Weboberfläche für ein kleines Team und die Trennung zwischen Umgebungen statt Datenbankanmeldedaten, die automatisch ablaufen. Dafür benötigen Sie PostgreSQL, Redis und ein TLS-Zertifikat. Diese Komponenten müssen Sie patchen und sichern.

Was passiert, wenn der Secrets-Dienst nicht verfügbar ist und Ihre Anwendung neu startet

Diese Frage entscheidet, ob ein Secrets-Dienst auf einem einzelnen Server betrieben werden sollte. Dateien sind lesbar, bevor das Netzwerk startet. Ein Dienst ist das nicht.

Starten Sie den Server neu, starten Ihre Anwendung und OpenBao gleichzeitig. Die Anwendung fordert ihr Datenbankpasswort an, OpenBao ist noch versiegelt, die Anfrage schlägt fehl, und systemd startet die Anwendung so lange in einer Schleife neu, bis jemand manuell Unseal-Shares eingibt. Nichts ist defekt. Aber es läuft auch nichts.

Dafür gibt es zwei sinnvolle Vorgehensweisen. Ordnen Sie die Units und lassen Sie die Anwendung Wiederholungsversuche ausführen: After= den Secrets-Dienst sowie Restart=on-failure und eine RestartSec=, die lang genug ist, damit die API nicht dauerhaft mit Anfragen belastet wird. Oder rufen Sie die Secrets beim Deployment statt beim Booten ab: Schreiben Sie das Secret in eine Datei mit dem Modus 600 oder in ein systemd-Credential, sodass das laufende System von einer Datei und nicht von einer API abhängt.

Der Ablauf von Tokens ist dasselbe Problem, nur auf einer langsameren Zeitskala. OpenBao-Tokens und Leases haben eine Gültigkeitsdauer. Ein lang laufender Prozess, der seine Tokens nie erneuert, verliert daher den Zugriff zu einem Zeitpunkt, der in keinem Zusammenhang mit einem Deployment steht. Dieser Fehler ist gerade deshalb schwer verständlich, weil an diesem Tag nichts geändert wurde.

Den Secret-Store selbst sichern

Jede Option hier hat einen Schlüssel. Ein Backup ohne diesen Schlüssel ist wertlos. Notieren Sie, wo er gespeichert ist.

Bei einer env-Datei ist die Datei selbst das Geheimnis. Das Backup muss daher verschlüsselt werden. Bei SOPS kann die verschlüsselte Datei an einem beliebigen öffentlich zugänglichen Ort liegen. Der private age-Schlüssel unter ~/.config/sops/age/keys.txt darf jedoch nicht verloren gehen. Bei systemd-Credentials sichern Sie /var/lib/systemd/credential.secret zusammen mit den .cred-Dateien. Bei Infisical erstellen Sie einen PostgreSQL-Dump und speichern ENCRYPTION_KEY getrennt davon.

OpenBao mit Raft-Speicher erstellt seinen eigenen Snapshot:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

Der Snapshot enthält Ihren verschlüsselten Speicher. Für die Wiederherstellung auf einem neuen Server benötigen Sie daher weiterhin die Unseal-Anteile aus bao operator init. Ein nächtlicher Job, der Snapshots in einen Objektspeicher kopiert, während die Anteile nirgendwo gespeichert sind, ist kein brauchbares Backup. Testen Sie die Wiederherstellung auf einem Wegwerf-VPS, bevor Sie sich darauf verlassen.

Überwachungsprotokollierung: Wer hat welches Secret gelesen?

Dateien liefern keine Überwachungsspur. Die Berechtigungsbits und der Eigentümer zeigen, wer das Secret lesen könnte. Sie zeigen nie, wer es tatsächlich gelesen hat. auditd mit einer Überwachung des Pfads ist der beste Ersatz. Es meldet, dass eine Datei geöffnet wurde, aber nicht, welcher Wert verwendet wurde.

OpenBao protokolliert jede Anfrage in ein Audit-Gerät, das Sie ausdrücklich aktivieren:

bao audit enable file file_path=/var/log/openbao_audit.log

Zwei Eigenschaften dieses Protokolls beeinflussen den Betrieb des Servers. Die meisten Zeichenfolgen in Anfragen und Antworten werden mit HMAC-SHA256 und einem Salt gehasht. Dadurch können Sie einen bereits bekannten Wert mit dem Protokoll abgleichen, ohne dass das Protokoll selbst den Klartext enthält. Ganzzahlen und boolesche Werte werden im Klartext geschrieben. Ein numerisches Secret ist durch dieses Hashing daher nicht geschützt.

Dann gibt es eine wichtige betriebliche Falle: OpenBao beantwortet keine Anfragen, wenn kein aktiviertes Audit-Gerät sie protokollieren kann. Ein Gerät, das blockierend fehlschlägt, lässt Anfragen hängen, bis jemand das Problem behebt. Ein volles Dateisystem auf /var/log setzt Ihre Secrets-API absichtlich außer Betrieb. Geben Sie dem Audit-Protokoll von Anfang an eigenen Speicherplatz und richten Sie am ersten Tag eine logrotate-Regel ein, nicht erst nach dem ersten Ausfall.

Welchen selbst gehosteten Secrets Manager sollten Sie betreiben?

Zählen Sie die Computer und die Benutzer und treffen Sie dann eine Auswahl.

1. Ein Computer, eine Person: Verwenden Sie eine Umgebungsdatei mit den Berechtigungen 600, die root gehört und von einem Dienstbenutzer gelesen wird. Verwenden Sie systemd Credentials, wenn der Wert nicht in der Prozessumgebung stehen soll.
2. Ein Computer, zwei bis fünf Personen, die Konfiguration befindet sich bereits in git: Verwenden Sie SOPS mit age. Jede Person erhält ein Schlüsselpaar, und .sops.yaml führt jeden öffentlichen Schlüssel auf, der zum Entschlüsseln berechtigt ist.
3. Mehrere Computer, ein Konfigurations-Repository, kein Bedarf an Credentials mit Ablaufzeit: Verwenden Sie weiterhin SOPS mit age, mit einem Empfängerschlüssel pro Host. Ein gestohlener Hostschlüssel kann dann nur die Dateien dieses Hosts entschlüsseln.
4. Mehrere Computer und mehrere Teams, die tatsächlich Datenbank-Credentials mit einer Gültigkeitsdauer sowie einen Audit-Trail benötigen, der von jemandem ausgewertet wird: Verwenden Sie OpenBao. Planen Sie außerdem monatlich eine Stunde Betreiberzeit für das Aufheben der Versiegelung und Wiederherstellungstests ein.

Die zugrunde liegende Regel ist in allen vier Fällen gleich. Betreiben Sie die kleinste Lösung, die eine klar benennbare Anforderung erfüllt. Ein Secrets Manager, der nicht verfügbar ist, ist nicht von einem Secrets Manager zu unterscheiden, der leer ist.

FAQ

Ist ein selbst gehosteter Secrets Manager für ein einzelnes VPS sinnvoll?

In der Regel nicht, wenn Sie einen Dienst wie OpenBao oder Infisical meinen. Auf einem einzelnen System mit einer oder zwei Personen bietet eine Umgebungsdatei mit den Rechten 600 oder ein verschlüsseltes systemd-Credential denselben Schutz vor anderen lokalen Benutzern. Dabei ist kein Unseal-Schritt erforderlich, und Sie müssen keinen zusätzlichen Dienst patchen. Ein Secrets-Dienst lohnt sich, sobald Sie mehrere Systeme und mehrere Personen verwalten oder tatsächlich Zugangsdaten benötigen, die ohne manuelle Rotation ablaufen.

Was ist der Unterschied zwischen einem Passwortmanager und einem Secrets Manager?

Ein Passwortmanager speichert Zugangsdaten, die eine Person eingibt, und wird von einem Menschen entsperrt, solange dieser anwesend ist. Ein Secrets Manager stellt Zugangsdaten für Prozesse bereit und muss daher um 03:00 funktionieren, ohne dass jemand den Vorgang überwacht. Daraus ergibt sich der entscheidende Unterschied: Bei einem gesperrten Passwortmanager müssen Sie ein Master-Passwort erneut eingeben. Ein versiegelter Secrets Manager stoppt dagegen jeden Dienst, der während der Versiegelung neu gestartet wird.

Was passiert mit meinen Anwendungen, wenn OpenBao nach einem Reboot versiegelt ist?

Sie können ihre Secrets nicht abrufen und starten daher nicht. systemd startet sie in einer Schleife neu, bis jemand das Unseal-Quorum bereitstellt, das standardmäßig 3 von 5 Shares umfasst. OpenBao hält den Root-Key nur im Arbeitsspeicher. Deshalb wird es bei jedem Neustart erneut versiegelt. Aktivieren Sie entweder Auto-Unseal und akzeptieren Sie, dass der Unseal-Key auf einem einzelnen VPS letztlich auf derselben Festplatte wie die Daten liegt. Alternativ schreiben Sie die Secrets beim Deployment in eine Datei, damit der Systemstart nie von der API abhängt.

Kann ich mit SOPS verschlüsselte Dateien in ein öffentliches Repository übernehmen?

Die Werte sind verschlüsselt und daher vor Personen ohne den privaten age-Key geschützt. Die Schlüssel sind jedoch nicht verschlüsselt. Ein Leser kann sehen, dass Sie STRIPE_SECRET_KEY und SMTP_PASSWORD besitzen, und wie häufig sich beide ändern. Für die meisten Projekte ist diese Metadateninformation akzeptabel, für einige jedoch nicht. Halten Sie den privaten age-Key aus dem Repository heraus und führen Sie sops updatekeys für jede vorhandene Datei aus, sobald Sie einen Empfänger hinzufügen oder entfernen.