Self-Hosted-Secrets-Manager für einen VPS im Vergleich

Was ein Self-Hosted-Secrets-Manager leistet, was ein Passwortmanager nicht leistet

Ein Self-Hosted-Secrets-Manager stellt Zugangsdaten für Prozesse bereit. Ein Passwortmanager stellt Zugangsdaten für Menschen bereit. Alles Weitere ergibt sich aus diesem einen Unterschied. Ein Passwortmanager wird von einem anwesenden Menschen entsperrt, der aufmerksam ist. 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 lediglich lästig: Sie geben das Masterpasswort erneut ein. Ein versiegelter Secrets-Manager verursacht einen 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 Problem auf der menschlichen Seite gut. Das Problem auf der Maschinenseite löst es nicht, und dafür wurde es auch nie entwickelt. Wenn Sie einen solchen Dienst parallel dazu betreiben, sollten Sie vor allem dessen Admin-Token und Backup-Datei absichern, nicht die Tresorinhalte, die der Client bereits verschlüsselt. Eine Härtung von Vaultwarden behandelt beide Punkte.

Die realistischen Optionen für einen Server lassen sich in zwei Gruppen einteilen. 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: Sie werden im Ruhezustand verschlüsselt und von einem bereits laufenden Prozess entschlüsselt. Es gibt nichts Zusätzliches zu überwachen.

Hier ist die klare Antwort vorweg. Für einen einzelnen Server mit einer oder zwei Personen sind dateibasierte Optionen normalerweise die richtige Wahl. Ein OpenBao, den niemand korrekt entsiegelt und bei dem niemand Zugangsdaten rotiert, ist schlechter als eine Env-Datei mit den Rechten mode 600. Er fügt eine weitere Komponente und ein Backup hinzu, das Sie wahrscheinlich falsch erstellen, und bietet Ihnen keine Rotation, die Sie nicht ohnehin bereits manuell durchführen.

Ist eine Env-Datei mit dem Modus 600 ausreichend?

Oft ja. Die Bedrohung, gegen die sie schützt, ist ein anderer Benutzer auf dem System, der Ihr Datenbankpasswort liest. Unix-Dateiberechtigungen verhindern das, und zwar 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 dies 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 tatsächlich wirksam.

Das Datenleck entsteht im nächsten Schritt. Eine systemd-Unit mit EnvironmentFile= kopiert 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'

Der Befehl gibt Ihre Geheimnisse im Klartext aus, 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, sieht dieselben Daten. Das gilt auch für jedes Tool, das unter demselben Benutzerkonto ausgeführt wird. Deshalb beginnt das Heraushalten 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üsselungswerkzeug mit genau einem Schlüsselpaar und ohne Schlüsselserver. Zusammen können Sie damit secrets.enc.yaml direkt neben Ihrem Code committen. git diff zeigt weiterhin, welche Einstellung geändert wurde, ohne offenzulegen, in welchen Wert sie geändert wurde.

age ist in Ubuntu 24.04 als Paket verfügbar. SOPS ist dort nicht enthalten. Laden Sie daher das .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 unter .sops.yaml im Wurzelverzeichnis des Repositorys ab. Dann müssen Sie den Empfänger nicht bei jedem Aufruf in der Befehlszeile angeben.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

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

Eine Regel ohne path_regex stimmt mit allem überein. Das ist zunächst das gewünschte Verhalten. Wenn Sie später eine Regel hinzufügen, formulieren Sie sie so, dass sie auf die Datei passt, die Sie an sops übergeben. Regeln werden gegen den Eingabepfad geprüft, nicht gegen die Datei, in die Sie die Ausgabe umleiten.

Übergeben Sie die Werte zur Laufzeit nur einem Prozess:

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

sops exec-env entschlüsselt die Werte im Speicher und setzt sie in der Umgebung des Kindprozesses. Dadurch wird kein Klartext auf die Festplatte geschrieben. Der Hinweis zur Umgebung aus dem vorherigen Abschnitt gilt für diesen Kindprozess weiterhin.

Hier führen zwei Dinge 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 in der Unit explizit. Außerdem verschlüsselt das Bearbeiten von .sops.yaml keine bereits vorhandenen Dateien erneut. Das Hinzufügen des öffentlichen Schlüssels eines Kollegen wirkt 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 verwaltet wird, erreichen Sie mit der Verschlüsselung derselben Werte mit Ansible Vault dasselbe Ziel ohne ein zweites Werkzeug.

systemd-Anmeldeinformationen: Geheimnisse, die nie die Umgebung erreichen

Ubuntu 24.04 enthält systemd 255. Daher ist keine Installation erforderlich. systemd-creds verschlüsselt ein Geheimnis auf dem Host. systemd entschlüsselt es in ein privates Verzeichnis, das nur der betreffende Dienst lesen 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. 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 -

Prüfen Sie, mit welchem Schlüssel die Datei verschlüsselt wurde. Davon hängt ab, ob Ihr Backup später verwendbar ist. Das standardmäßige --with-key=auto verwendet den TPM2-Chip (Trusted Platform Module Version 2), wenn ein solcher vorhanden und nutzbar 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 neuen VPS wiederherstellen, auf dem diese Datei fehlt, kann nichts entschlüsselt werden. Kopieren Sie credential.secret ebenfalls in das Backup. Alternativ können Sie den Klartext an einem Ort aufbewahren, 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 dieses Format 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. Ihr einziger Schutz sind Dateimodus und Eigentümer. Setzen Sie beides selbst, weil Compose eine weltweit lesbare Datei problemlos einbindet, ohne eine Warnung auszugeben. Die umfassenderen Abwägungen gegenüber der einfachen Abkürzung env_file finden Sie im Leitfaden zu Compose-Env-Dateien und Secrets.

Was OpenBao und Vault im Betrieb tatsächlich kosten

OpenBao ist der von der Linux Foundation verwaltete Fork von HashiCorp Vault. Das Projekt begann, 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 Befehlsoberfläche beibehalten hat.

docker pull docker.io/openbao/openbao

Debian- und Ubuntu-Pakete finden Sie auf der OpenBao-Downloadseite, wenn Sie die Aktualisierungen lieber mit apt verwalten möchten. Der Server benötigt eine Konfigurationsdatei mit einem Listener und einem Speicher-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 Entsperren sind 3 davon erforderlich. Dabei handelt es sich um die Flags -key-shares und -key-threshold. OpenBao gibt die Anteile und das anfängliche Root-Token einmal aus und danach nicht wieder.

Nun folgt der Teil, den die meisten Vergleiche auslassen. Ein neu gestarteter Server ist ein gesperrter Server. OpenBao hält den Root-Schlüssel nur im Arbeitsspeicher. Nach einem Neustart kann OpenBao seinen eigenen Speicher daher erst wieder entschlüsseln, wenn jemand die erforderliche Anzahl an Anteilen bereitstellt. Ein Kernel-Update oder die Beendigung wegen Speichermangels führt deshalb zu einem gesperrten Server, bei dem sich Anwendungen nicht anmelden können.

Auf einem VPS für eine einzelne Person bietet die Aufteilung nach Shamir keinen Schutz, weil alle 5 Anteile im selben Passwortmanager derselben Person landen. Auto-Unseal verlagert den Schlüssel auf ein vertrauenswürdiges Gerät oder einen vertrauenswürdigen Dienst. In einer großen Cloud ist das normalerweise ein verwalteter Schlüsseldienst. Auf Ihrem VPS ist es meist eine Schlüsseldatei auf demselben Datenträger wie die Daten, die sie schützt. Das ist eine tatsächliche Verringerung der Sicherheit. Dafür startet der Server nach einem Reboot selbstständig wieder. Treffen diese Abwägung bewusst und dokumentieren Sie, für welche Variante Sie sich entschieden haben.

Infisical: eine Benutzeroberfläche, eine Datenbank und ein Hauptschlüssel, den Sie weiterhin selbst verwalten

Infisical ist eine Secrets-Plattform mit Weboberfläche, Projekten, Umgebungen und benutzerbezogener 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, und 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 in PostgreSQL verschlüsselt. Wenn Sie ihn verlieren, wird aus einer vollständigen Datenbanksicherung 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 des Protokolls. Andernfalls funktioniert die Anmeldeweiterleitung nicht.

Infisical eignet sich besser als OpenBao, wenn Sie tatsächlich eine Lösung für Benutzer benötigen: eine Weboberfläche für ein kleines Team und eine Trennung zwischen Umgebungen, statt Datenbankzugangsdaten, die automatisch ablaufen. Dafür benötigen Sie PostgreSQL, Redis und ein TLS-Zertifikat. Diese Komponenten müssen Sie ebenfalls 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 verfügbar, bevor das Netzwerk startet. Ein Dienst ist das nicht.

Starten Sie den Server neu, beginnen 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 in einer Schleife neu, bis jemand Unseal-Shares eingibt. Nichts ist defekt. Es läuft aber auch nichts.

Dafür gibt es zwei sinnvolle Vorgehensweisen. Ordnen Sie die Units und lassen Sie die Anwendung erneut versuchen: After= den Secrets-Dienst sowie Restart=on-failure und RestartSec= für eine ausreichend lange Zeit, damit die API nicht ständig erneut abgefragt wird. Oder rufen Sie das Secret beim Deployment statt beim Boot ab: Schreiben Sie es in eine Datei mit den Berechtigungen 600 oder in ein systemd Credential. Das laufende System hängt dann von einer Datei und nicht von einer API ab.

Der Ablauf von Tokens ist dasselbe Problem, nur auf einer langsameren Zeitskala. OpenBao-Tokens und Leases haben eine Gültigkeitsdauer. Ein Prozess, der lange läuft und seine Tokens nie erneuert, verliert daher den Zugriff zu einem Zeitpunkt, der unabhängig von jedem Deployment ist. Dieser Fehler ist gerade deshalb schwer verständlich, weil sich an diesem Tag nichts geändert hat.

Den Store selbst sichern

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

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 öffentlichen 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 einen 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-Shares aus bao operator init. Ein nächtlicher Job, der Snapshots in einen Objektspeicher kopiert, während die Shares nirgendwo gespeichert sind, ist kein Backup. Testen Sie die Wiederherstellung auf einem Wegwerf-VPS, bevor Sie sich darauf verlassen.

Audit-Protokollierung: Wer hat welches Secret gelesen?

Dateien liefern keine Audit-Spur. Modus und 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 nächstbeste Ersatz. Dabei wird gemeldet, dass eine Datei geöffnet wurde, nicht welcher Wert verwendet wurde.

OpenBao protokolliert jede Anfrage auf einem 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 Klartext enthält. Ganzzahlen und boolesche Werte werden im Klartext geschrieben. Ein numerisches Secret ist durch dieses Hashing daher nicht geschützt.

Dann folgt die betriebliche Falle: OpenBao beantwortet keine Anfragen, wenn kein aktiviertes Audit-Gerät sie protokollieren kann. Ein Gerät, das auf blockierende Weise ausfällt, lässt Anfragen hängen, bis jemand das Problem behebt. Ein volles Dateisystem auf /var/log legt Ihre Secrets-API absichtlich still. Weisen Sie dem Audit-Protokoll am ersten Tag eigenen Speicherplatz und eine logrotate-Regel zu, nicht erst nach dem ersten Ausfall.

Welchen selbst gehosteten Secrets Manager sollten Sie betreiben?

Zählen Sie die Maschinen und die Personen. Treffen Sie danach die Auswahl.

1. Eine Maschine, eine Person: eine Env-Datei mit den Berechtigungen 600, die root gehört und von einem Servicebenutzer gelesen wird. Verwenden Sie zusätzlich systemd Credentials, wenn der Wert nicht in der Prozessumgebung stehen soll.
2. Eine Maschine, zwei bis fünf Personen, die Konfiguration liegt bereits in git: 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 Maschinen, ein Konfigurations-Repository, kein Bedarf an ablaufenden Zugangsdaten: weiterhin SOPS mit age, mit einem Empfängerschlüssel pro Host. Dadurch entschlüsselt ein gestohlener Hostschlüssel nur die Dateien dieses Hosts.
4. Mehrere Maschinen und mehrere Teams, die tatsächlich Datenbankzugangsdaten mit einer Gültigkeitsdauer sowie einen Audit-Trail benötigen, der von jemandem ausgewertet wird: OpenBao. Planen Sie außerdem monatlich eine Stunde Betreiberzeit für das Aufheben der Versiegelung und Restore-Übungen 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, lässt sich nicht von einem Secrets Manager unterscheiden, der leer ist.

FAQ

Lohnt sich ein selbst gehosteter Secrets Manager für einen einzelnen VPS?

In der Regel nicht, wenn Sie einen Dienst wie OpenBao oder Infisical meinen. Auf einem System mit einer oder zwei Personen bietet eine Umgebungsdatei mit den Berechtigungen mode 600 oder ein verschlüsseltes systemd-Credential denselben Schutz vor einem anderen lokalen Benutzer. Dabei entfällt sowohl der Unseal-Schritt als auch ein zusätzlicher Dienst, der gepatcht werden muss. Ein Secrets-Dienst lohnt sich, sobald Sie mehrere Systeme und mehrere Personen haben oder Credentials benötigen, die ohne manuelle Rotation ablaufen.

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

Ein Passwortmanager speichert Credentials, die eine Person eingibt, und wird von einem Menschen entsperrt, solange dieser anwesend ist. Ein Secrets Manager stellt Credentials für Prozesse bereit und muss daher um 03:00 funktionieren, ohne dass jemand den Vorgang überwacht. Das ist 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?

Die Anwendungen können ihre Secrets nicht abrufen. Deshalb starten sie nicht, und systemd startet sie in einer Schleife neu, bis jemand den Unseal-Schwellenwert bereitstellt. Dieser beträgt standardmäßig 3 von 5 Shares. OpenBao hält den Root Key nur im Arbeitsspeicher. Daher wird OpenBao bei jedem Neustart erneut versiegelt. Aktivieren Sie entweder Auto-Unseal. Dann liegt der Unseal Key auf einem einzelnen VPS allerdings auf demselben Datenträger wie die Daten. Oder schreiben Sie die Secrets zum Deployment-Zeitpunkt in eine Datei, damit der Bootvorgang niemals von der API abhängt.

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

Die Werte sind verschlüsselt und daher vor Personen ohne den privaten age Key geschützt. Die Keys selbst sind nicht verschlüsselt: Ein Leser kann sehen, dass Sie STRIPE_SECRET_KEY und SMTP_PASSWORD besitzen und wie häufig sich die einzelnen Keys ändern. Diese Metadaten sind für die meisten Projekte 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.