GitOps

GitOps macht Git zur einzigen Quelle der Wahrheit für Infrastruktur und Anwendungen: Der Sollzustand liegt versioniert im Repository, Agents gleichen ihn kontinuierlich mit der Realität ab. Der Artikel erklärt das Pull-Prinzip samt Audit-Vorteilen und den Unterschied zum klassischen CI/CD-Deployment.

Was läuft gerade in der Produktion? In vielen Umgebungen ist diese Frage überraschend schwer zu beantworten: Deployments liefen über Skripte, jemand hat manuell nachjustiert, die Dokumentation hinkt hinterher. GitOps beantwortet die Frage mit einem Blick ins Repository. Der gewünschte Zustand von Infrastruktur und Anwendungen steht deklarativ in Git, und automatische Agents sorgen dafür, dass die Realität diesem Stand entspricht. Geprägt wurde der Begriff 2017 im Kubernetes-Umfeld, als Betriebsmuster für containerisierte Plattformen hat er sich seitdem breit etabliert.

Was ist GitOps?

GitOps ist ein Betriebsmodell für Cloud-native Umgebungen, das auf vier Prinzipien beruht. Erstens wird der Sollzustand deklarativ beschrieben: Konfigurationsdateien definieren, was laufen soll, kein Skript beschreibt, wie es dahin kommt. Zweitens liegt dieser Sollzustand versioniert und unveränderlich in Git, inklusive der kompletten Historie. Drittens holen sich Software-Agents Änderungen selbstständig ab, statt dass ein externes System sie in die Umgebung schiebt. Viertens gleichen diese Agents Ist und Soll kontinuierlich ab und korrigieren Abweichungen automatisch. Entstanden ist das Modell im Kubernetes-Umfeld. Die Prinzipien lassen sich aber auf jedes deklarativ steuerbare System übertragen, etwa auf Netzwerk- und Sicherheitsrichtlinien.

So funktioniert es

Deklarative Definition: Manifeste beschreiben Anwendungen samt Konfiguration als Zielzustand. Templating und Overlays halten die Definitionen über mehrere Umgebungen hinweg wartbar.
Änderung per Pull Request: Jede Anpassung durchläuft denselben Weg wie Anwendungscode: Branch, Review, Freigabe, Merge. Einen legitimen Weg an diesem Prozess vorbei gibt es im Zielbild nicht.
Pull statt Push: Ein Agent innerhalb der Zielumgebung beobachtet das Repository und wendet Änderungen selbst an. Externe Systeme benötigen dadurch keinen privilegierten Zugang in die Umgebung hinein.
Kontinuierliche Reconciliation: Der Agent vergleicht laufend den realen Zustand mit dem deklarierten. Manuelle Eingriffe direkt am System werden erkannt und automatisch zurückgesetzt.
Rollback über die Historie: Ein fehlerhafter Stand wird durch das Zurücknehmen des entsprechenden Commits korrigiert. Die Wiederherstellung ist damit genauso nachvollziehbar wie die ursprüngliche Änderung.

Warum es wichtig ist

Lückenloser Audit-Trail: Jede Änderung an der Umgebung existiert als Commit mit Autor, Zeitstempel und Review. Auditoren erhalten die Änderungshistorie ohne zusätzlich gepflegte Dokumentation.
Weniger privilegierte Zugänge: Da Agents Änderungen aus der Umgebung heraus abholen, entfallen mächtige Deployment-Zugänge von außen. Das verkleinert die Angriffsfläche spürbar.
Reproduzierbarkeit: Eine Umgebung lässt sich aus dem Repository neu aufbauen. Das beschleunigt Disaster Recovery ebenso wie das Aufsetzen zusätzlicher Cluster oder Standorte.
Schutz vor Konfigurationsdrift: Undokumentierte Handgriffe direkt am System überleben die nächste Reconciliation nicht. Ist und Soll bleiben dauerhaft synchron.
Klare Verantwortlichkeiten: Der Pull-Request-Prozess erzwingt Reviews und dokumentiert Entscheidungen genau dort, wo die Änderung stattfindet.
Ein Prozess für alles: Anwendungs- und Infrastrukturänderungen folgen demselben Weg. Das reduziert Sonderwissen und erleichtert Vertretungen im Team.

Typische Szenarien

GitOps spielt seine Stärken überall dort aus, wo viele gleichartige Umgebungen betrieben werden. Plattform-Teams verwalten Dutzende Kubernetes-Cluster aus einem Repository und rollen Änderungen kontrolliert über Stages aus. In regulierten Branchen liefert das Modell den Nachweis, wer welche Änderung wann freigegeben hat, ohne separat gepflegtes Änderungsregister. Beim Disaster Recovery verkürzt sich die Wiederherstellung deutlich, weil der komplette Sollzustand versioniert vorliegt. Und zunehmend wandern auch Netzwerk- und Segmentierungsrichtlinien in diesen Prozess: Firewallregeln und Policies werden wie Code im Review geprüft und anschließend automatisch ausgerollt. Attraktiv ist das Pull-Modell zudem für Edge-Standorte mit schmaler Anbindung, weil jeder Standort sich selbst versorgt, sobald er das Repository erreicht.

GitOps und klassisches CI/CD-Deployment: die Abgrenzung

Im klassischen Modell übernimmt die CI/CD-Pipeline auch das Deployment: Nach Build und Tests schiebt sie das Ergebnis per Skript und hinterlegten Zugangsdaten in die Zielumgebung. Das funktioniert, hat aber zwei strukturelle Schwächen. Die Pipeline braucht dauerhafte, weitreichende Zugriffsrechte auf die Produktion. Und nach dem Deployment endet ihre Verantwortung: Driftet die Umgebung danach, merkt es niemand. GitOps trennt die Zuständigkeiten. Die CI-Pipeline baut und testet weiterhin Artefakte, das Ausrollen übernimmt jedoch der Agent in der Umgebung, der zusätzlich dauerhaft über die Einhaltung des Sollzustands wacht. GitOps ersetzt CI also keineswegs, es ersetzt den Push-Schritt am Ende der Kette. Für Bestandsumgebungen empfiehlt sich der schrittweise Umstieg: zunächst eine unkritische Anwendung, danach der Rest, sobald Prozesse und Zuständigkeiten eingespielt sind.

Umsetzung mit KAEMI

Die Prinzipien hinter GitOps prägen auch den Netzwerkbetrieb von KAEMI. Bei der Mikrosegmentierung entstehen Richtlinien deklarativ: Sie beschreiben, welche Workloads miteinander kommunizieren dürfen, und werden automatisiert durchgesetzt statt von Hand auf einzelnen Systemen gepflegt. Änderungen bleiben dadurch nachvollziehbar, Abweichungen fallen auf. Von diesem Modell profitieren Sie auch ohne Kubernetes, denn nachvollziehbare Richtlinienpflege ist in jedem Netzwerk ein Gewinn. Für die Einführung solcher Arbeitsweisen unterstützt KAEMI mit Professional Services : von der Bewertung Ihrer bestehenden Deployment-Prozesse bis zum dauerhaften Betrieb der automatisierten Regelwerke als Managed Service. Wenn Sie Ihre Infrastruktur- und Sicherheitsrichtlinien in versionierte, prüfbare Prozesse überführen wollen, erreichen Sie uns über Kontakt .

Häufige Fragen zu GitOps

Funktioniert GitOps ausschließlich mit Kubernetes?

Nein, aber dort ist es entstanden und am weitesten gereift. Kubernetes eignet sich besonders, weil es deklarativ arbeitet und Agents die Reconciliation direkt im Cluster übernehmen können. Die Prinzipien, versionierter Sollzustand und automatischer Abgleich, lassen sich auf andere deklarativ steuerbare Systeme übertragen, etwa Cloud-Ressourcen oder Netzwerkrichtlinien. Entscheidend ist, dass sich der Zielzustand als Code beschreiben lässt.

Was passiert bei manuellen Änderungen direkt an der Umgebung?

Der Agent erkennt die Abweichung beim nächsten Abgleich und setzt sie auf den in Git deklarierten Stand zurück. Das schützt vor undokumentierten Eingriffen, verlangt aber Disziplin: Auch Notfalleingriffe müssen anschließend in das Repository zurückfließen. Bewährt haben sich definierte Break-Glass-Prozesse, bei denen die Reconciliation kurzzeitig pausiert und der Eingriff danach als Commit nachgezogen wird.

Ersetzt GitOps meine bestehende CI-Pipeline?

Nein. Die CI-Pipeline behält ihre Aufgaben: Code bauen, Tests ausführen, Artefakte erzeugen und in eine Registry veröffentlichen. GitOps übernimmt den Schritt danach, das Ausrollen in die Zielumgebung. Statt dass die Pipeline in die Produktion schiebt, aktualisiert sie eine Versionsangabe im Konfigurations-Repository, und der Agent in der Umgebung wendet die Änderung an. Beide Bausteine ergänzen sich.

Welche Sicherheitsvorteile bietet das Pull-Prinzip?

Beim Push-Modell besitzt ein externes System dauerhafte Zugangsdaten mit weitreichenden Rechten auf die Produktion, ein lohnendes Angriffsziel. Beim Pull-Prinzip holt der Agent Änderungen aus der Umgebung heraus ab. Nach außen genügt Lesezugriff auf Repository und Registry. Wird die CI-Umgebung kompromittiert, fehlt dem Angreifer der direkte Deployment-Zugang, und jede wirksame Änderung bleibt als Commit sichtbar.

Eignet sich GitOps auch für Netzwerk- und Sicherheitsrichtlinien?

Ja, die Übertragung liegt nahe. Segmentierungsregeln und Firewall-Policies sind deklarative Beschreibungen erlaubter Kommunikation und profitieren von denselben Mechanismen: Review vor jeder Änderung, lückenlose Historie für Audits und automatischer Abgleich gegen den durchgesetzten Zustand. Manuell gepflegte Regelwerke driften dagegen erfahrungsgemäß schnell. KAEMI setzt diesen Gedanken im Betrieb von Segmentierungsrichtlinien um.