Ein Meinungsbeitrag stellt sich gegen die verbreitete Praxis, Secrets über Umgebungsvariablen zu übergeben, und plädiert dafür, sie stattdessen direkt aus strukturierten Konfigurationsdateien im Anwendungscode zu laden.

Das erste Argument des Autors ist Konsistenz: Die Mischung aus ini/yaml/json-Konfigurationsdateien und separaten Umgebungsvariablen (wie es bei Docker-Setups oft vorkommt, aufgeteilt zwischen Compose-Dateien und .env-Dateien) führt zu einem fragmentierten, fehleranfälligen Setup.

Zweitens vermeidet das Laden von Secrets innerhalb der Anwendung plattformspezifische Eigenheiten bei der Injektion. Der Autor erinnert sich an einen früheren Job, bei dem Secrets zur Laufzeit aus S3 geladen wurden, während die Anwendung auf AWS ECS lief – denn das Setzen als Umgebungsvariablen hätte dort riskiert, sie über die ECS-Konsole preiszugeben.

Drittens macht sich der Autor wenig Sorgen über Secrets auf der Festplatte, da stets vollständige Festplattenverschlüsselung genutzt wird, ergänzt durch encfs/gocryptfs, wenn das nicht ausreicht. Sollte ein Angreifer beides überwinden, sei ohnehin die gesamte Maschine kompromittiert – Umgebungsvariablen wären dann auch nicht sicherer.

Schließlich empfindet der Autor JSON/YAML bei Anwendungen mit tiefen, komplexen Datenstrukturen als deutlich handhabbarer als flache Umgebungsvariablen.