Wie handhabst du Secrets in einer Build- und Deployment-Pipeline?

Halte langlebige Credentials komplett aus der Pipeline raus. Nutze Workload Identity Federation, damit der CI-Job ein kurzlebiges OIDC-Token gegen eine eng geschnittene Rolle tauscht, und hol Anwendungs-Secrets zur Laufzeit aus einem Secrets Manager statt sie beim Build zu injizieren. Schneide jedes Secret auf eine Umgebung und einen Konsumenten zu, rotiere automatisch, auditiere Zugriffe und maskiere sie in Logs. Nie Secrets in Images backen oder committen, auch nicht verschlüsselt ohne Key Management.

Meine Ausgangsposition ist, dass die Pipeline keine langlebigen Cloud-Credentials halten sollte. Der CI-Provider stellt ein signiertes Identity Token für den Job aus, die Cloud vertraut diesem Issuer, und der Job tauscht es gegen eine Rolle, die Minuten gilt und auf eine Umgebung beschränkt ist. Das löscht die ganze Kategorie eines geleakten statischen Keys, der drei Jahre in einer Repository-Einstellung liegt. Anwendungs-Secrets sind eine eigene Sache und gehören zur Laufzeit, vom Workload mit seiner eigenen Identität aus einem Secrets Manager geholt, damit ein Datenbankpasswort nie durch den Build läuft. Wenn ich verschlüsselte Secrets in git halten muss, etwa in einem GitOps-Repository, sind sie gegen einen Key-Management-Service verschlüsselt, denn was ich in Wahrheit kontrolliere, ist das Entschlüsselungsrecht und nicht die Datei. Alles ist eng geschnitten, wird nach Plan rotiert und Zugriffe werden geloggt. Und ich plane für Leaks: erst widerrufen, dann rotieren, dann aus dem Audit Trail den Blast Radius bestimmen, denn erst beweisen zu wollen, dass es niemand benutzt hat, ist die falsche Reihenfolge.