GitOps mit ArgoCD und Helm: Auditierbare Releases in regulierten Umgebungen

Warum Push-basierte Deployments bei Audits scheitern

Ich sehe immer noch Teams, die per kubectl apply vom Laptop nach Kubernetes deployen oder eine CI-Pipeline bei jedem Merge direkt in einen Cluster pushen lassen. Beides funktioniert, bis jemand die Frage stellt, die jede regulierte Umgebung irgendwann stellt: Was lief an einem bestimmten Datum in Produktion, wer hat es freigegeben, und können Sie das belegen? Bei Push-basierten Deployments lautet die ehrliche Antwort meist "wir sind uns nicht ganz sicher". Der tatsächliche Cluster-Zustand und der dokumentierte Soll-Zustand driften auseinander, sobald ein manuelles kubectl edit oder ein Notfall-Hotfix die Pipeline umgeht. Auditoren akzeptieren "schauen Sie in die Deployment-Logs" nicht als befriedigende Antwort, und ich sollte das auch nicht.

Das GitOps-Modell

Die Lösung, zu der ich greife, ist GitOps: Der gewünschte Zustand jedes Clusters lebt in einem Git-Repository, und ein Reconciliation-Controller (ich nutze ArgoCD) vergleicht diesen deklarierten Zustand kontinuierlich mit dem, was tatsächlich läuft, und korrigiert jede Abweichung automatisch. Helm-Charts templaten die Kubernetes-Manifeste, sodass ein einzelnes Chart eine Anwendung beschreibt, während umgebungsspezifische Values-Dateien die Unterschiede zwischen Dev, Staging und Produktion liefern. Nichts erreicht einen Cluster außer über eine Änderung in Git, und jede Änderung in Git ist ein geprüfter Merge Request. Genau diese eine Einschränkung, nie direkter Cluster-Zugriff, macht aus "vertrauen Sie mir" ein "hier ist der Commit".

Promotion über mehrere Umgebungen

Mit dieser Struktur wird die Promotion eines Releases zwischen Umgebungen vom Deploy-Skript zur Git-Operation. Dieselbe Chart-Version wandert von Staging nach Produktion, indem eine Values-Datei-Änderung gemerged wird, die den Image-Tag oder die Konfiguration für diese Umgebung anhebt. Ein Rollback ist ein git revert, kein Gerangel um die vorherige Helm-Release-Nummer. Weil ArgoCD kontinuierlich abgleicht, folgt der Cluster in dem Moment, in dem der Revert landet, ohne separates Rollback-Tooling und ohne manuellen Eingriff. Das bedeutet auch: Die Promotion-Historie ist die Commit-Historie. Ich kann auf einen Pull Request zeigen und genau belegen, wann eine Version Produktion erreicht hat und wer sie freigegeben hat.

Security-Stages in CI

GitOps regelt, was nach der Freigabe einer Änderung passiert, aber ich will trotzdem Vertrauen in das haben, was vorgeschlagen wird. Ich lasse Build, Test und Security-Scanning als eigene Stages in GitLab CI laufen, bevor ein Image oder Chart überhaupt für eine Values-Datei-Änderung infrage kommt. Dependency-Scanning, Container-Image-Scanning und Policy-Checks gaten die Pipeline. Gebaute Artefakte werden in eine zentrale Registry gepusht und über einen unveränderlichen Tag referenziert, nie über latest, sodass das, was in Git beschrieben ist, exakt dem entspricht, was deployt wird, ohne Zweifel darüber, welcher Build gerade läuft.

Kernaussagen

• Deklarativer Soll-Zustand in Git schlägt imperative Deploy-Skripte für alles, was später auditiert werden muss.
• Kein manueller Cluster-Zugriff. Jede Änderung an laufender Infrastruktur ist ein geprüfter, gemergter Commit.
• Promotion und Rollback werden zu Git-Operationen: ein Merge oder ein Revert, kein Custom-Tooling.
• Security-Scanning gehört in die CI, bevor eine Änderung überhaupt zum Deployment vorgeschlagen wird.
• Der Audit-Trail ergibt sich daraus, wie das Deployment-Modell funktioniert, und ist damit kein separat zu pflegendes System.