Zum Inhalt springen

SOPS und age: Secrets ins Git, aber bitte mit Tarnkappe

28. Juli 2026 durch
SOPS und age: Secrets ins Git, aber bitte mit Tarnkappe
Torben Belz

Klartext-Secrets im Git-Repo sind wie Root-Passwort auf dem Whiteboard: technisch möglich, aber irgendwann steht jemand mit Kaffee davor und fragt unangenehme Dinge.

Wir wollten Konfigurationsdateien versionieren, inklusive Tokens, Passwörter und API-Keys. Aber eben nicht im Klartext. Die Kombi aus SOPS und age ist dafür ziemlich elegant: SOPS verschlüsselt strukturierte Dateien wie YAML, JSON, ENV oder INI. age kümmert sich um die moderne, schlanke Kryptografie. Kein GPG-Schlüsseldrama, kein Keyserver-Voodoo.

Erstmal installieren. Auf macOS:

brew install sops age

Unter Linux geht es je nach Distribution über Paketmanager oder direkt via GitHub-Releases. Danach erzeugen wir einen age-Key:

age-keygen -o ~/.config/sops/age/keys.txt

Die Ausgabe enthält zwei wichtige Teile:

public key: age1xyz...
AGE-SECRET-KEY-1...

Der public key darf in die Projektkonfiguration. Der private Key bleibt auf deiner Maschine. Nicht ins Repo. Nicht in Slack. Nicht „kurz zum Testen“ irgendwo hinkopieren. Wir kennen diese Tests.

Damit SOPS weiß, welche Dateien wie verschlüsselt werden sollen, legen wir im Repo eine .sops.yaml an:

creation_rules:
  - path_regex: .*\.secret\.yaml$
    age: age1xyz...

Damit sagen wir: Alles, was auf .secret.yaml endet, wird mit diesem age-Empfänger verschlüsselt.

Jetzt bauen wir eine Testdatei:

# app.secret.yaml
database:
  user: app
  password: super-geheim
api:
  token: "1234567890"

Verschlüsseln:

sops --encrypt --in-place app.secret.yaml

Danach sieht die Datei noch halbwegs lesbar aus, aber die Werte sind verschlüsselt. SOPS lässt Struktur und Keys stehen, verschlüsselt aber die Inhalte. Sehr angenehm für Code Reviews, weil man noch erkennt, *was* konfiguriert wird, aber nicht *womit*.

Bearbeiten geht ohne manuelles Entschlüsseln:

sops app.secret.yaml

SOPS öffnet deinen Editor, entschlüsselt temporär im Hintergrund und schreibt danach wieder verschlüsselt zurück. Sysadmin-Magie, aber die gute Sorte.

Wenn du die Datei lokal im Klartext brauchst, zum Beispiel für ein Deployment-Script:

sops --decrypt app.secret.yaml > app.yaml

Dann bitte direkt dafür sorgen, dass Klartextdateien nicht im Git landen:

# app.yaml
*.decrypted.*

Für Teams fügst du einfach mehrere age-Public-Keys in der .sops.yaml ein:

creation_rules:
  - path_regex: .*\.secret\.yaml$
    age: age1abc...,age1def...,age1xyz...

Wenn jemand das Team verlässt, wird es etwas handwerklich: Key entfernen und Dateien neu verschlüsseln:

sops updatekeys app.secret.yaml

In CI/CD funktioniert das ebenfalls. Der private age-Key kommt dann als Secret in dein CI-System, zum Beispiel als Variable SOPS_AGE_KEY. Vor dem Deployment:

export SOPS_AGE_KEY="$SOPS_AGE_KEY"
sops --decrypt app.secret.yaml > app.yaml

Wichtig: Der private Key ist ab jetzt Kronjuwel. Backup machen, aber sicher. Passwortmanager, Vault, HSM, was auch immer in deiner Umgebung nicht nach Bastelkeller riecht.

Unser Fazit nach dem Selbstversuch: SOPS plus age ist angenehm unspektakulär. Genau das will man bei Secrets. Dateien bleiben versionierbar, Diffs bleiben brauchbar, Klartext bleibt draußen. Git bekommt die Tarnkappe, und wir schlafen etwas ruhiger.

SOPS und age: Secrets ins Git, aber bitte mit Tarnkappe
Torben Belz 28. Juli 2026
Diesen Beitrag teilen