Welche Version läuft derzeit tatsächlich in der Produktion? Erstaunlich viele Organisationen können diese Frage nur mit Aufwand beantworten: Deployments erfolgten per Skript, jemand hat direkt am System nachgebessert, und die Dokumentation ist veraltet. GitOps löst das Problem an der Wurzel – ein Blick ins Repository genügt.
Der gewünschte Zustand von Infrastruktur und Anwendungen liegt dabei deklarativ in Git; automatische Agents stellen sicher, dass die reale Umgebung diesem Stand folgt. Entstanden ist der Begriff 2017 rund um Kubernetes. Als Betriebsmuster für containerisierte Plattformen ist er heute weit verbreitet.
Was ist GitOps?
GitOps bezeichnet ein Betriebsmodell für Cloud-native Umgebungen, das vier Grundsätze verbindet. Erstens: Der Sollzustand wird deklarativ formuliert – Konfigurationsdateien legen fest, was laufen soll, nicht über welche Einzelschritte es dorthin kommt. Zweitens: Dieser Sollzustand liegt versioniert und unveränderlich in Git, samt vollständiger Historie. Drittens: Software-Agents holen Änderungen selbstständig ab, statt dass ein externes System sie von außen in die Umgebung drückt. Viertens: Dieselben Agents vergleichen Ist und Soll fortlaufend und beheben Abweichungen automatisch. Geboren wurde das Modell im Kubernetes-Umfeld; die Prinzipien greifen jedoch bei jedem System, das sich deklarativ steuern lässt – bis hin zu Netzwerk- und Sicherheitsrichtlinien.
Funktionsweise
- Deklarative Beschreibung: Manifeste definieren Anwendungen und ihre Konfiguration als Zielzustand. Templating und Overlays halten die Definitionen über mehrere Umgebungen hinweg pflegbar.
- Änderungen über Pull Requests: Jede Anpassung nimmt denselben Weg wie Anwendungscode – Branch, Review, Freigabe, Merge. Einen legitimen Pfad an diesem Prozess vorbei sieht das Zielbild nicht vor.
- Pull statt Push: Ein Agent in der Zielumgebung beobachtet das Repository und wendet neue Stände eigenständig an. Externe Systeme brauchen dadurch keinen privilegierten Zugriff in die Umgebung hinein.
- Laufende Reconciliation: Der Agent prüft kontinuierlich, ob der reale Zustand dem deklarierten entspricht. Manuelle Eingriffe direkt am System fallen auf und werden automatisch zurückgedreht.
- Rollback per Historie: Ein fehlerhafter Stand wird korrigiert, indem der zugehörige Commit zurückgenommen wird. Die Wiederherstellung bleibt damit genauso nachvollziehbar wie die ursprüngliche Änderung.
Warum GitOps wichtig ist
- Vollständiger Audit-Trail: Jede Änderung existiert als Commit mit Autor, Zeitstempel und Review. Prüfer erhalten die komplette Historie, ohne dass jemand eine separate Dokumentation pflegt.
- Weniger privilegierte Zugänge: Weil Agents Änderungen aus der Umgebung heraus abholen, entfallen mächtige Deployment-Zugriffe von außen – die Angriffsfläche schrumpft messbar.
- Reproduzierbarkeit: Eine Umgebung lässt sich aus dem Repository neu erzeugen. Das beschleunigt Disaster Recovery ebenso wie den Aufbau zusätzlicher Cluster oder Standorte.
- Schutz vor Konfigurationsdrift: Undokumentierte Handgriffe am System überstehen die nächste Reconciliation nicht. Ist und Soll bleiben dauerhaft deckungsgleich.
- Klare Verantwortung: Der Pull-Request-Prozess erzwingt Reviews und hält Entscheidungen genau dort fest, wo die Änderung passiert.
- Ein Prozess für alles: Anwendungs- und Infrastrukturänderungen folgen demselben Ablauf. Das verringert Spezialwissen und erleichtert Vertretungen.
Typische Einsatzfelder
Seine Stärken zeigt GitOps überall dort, wo viele gleichartige Umgebungen laufen. Plattform-Teams steuern Dutzende Kubernetes-Cluster aus einem Repository und rollen Änderungen stufenweise über Stages aus. Regulierte Branchen erhalten den Nachweis, wer welche Änderung wann freigegeben hat – ohne eigenes Änderungsregister. Beim Disaster Recovery verkürzt sich die Wiederherstellung erheblich, weil der komplette Sollzustand versioniert vorliegt. Zunehmend wandern auch Netzwerk- und Segmentierungsrichtlinien in diesen Ablauf: Firewallregeln und Policies durchlaufen ein Review wie Code und werden anschließend automatisch verteilt. Für Edge-Standorte mit schmaler Anbindung ist das Pull-Modell zusätzlich attraktiv, weil sich jeder Standort selbst versorgt, sobald er das Repository erreicht.
Abgrenzung: GitOps und klassisches CI/CD-Deployment
Im klassischen Modell erledigt 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, trägt aber zwei strukturelle Schwächen in sich. Die Pipeline benötigt dauerhafte, weitreichende Rechte auf die Produktion. Und mit dem Deployment endet ihre Zuständigkeit – driftet die Umgebung anschließend, bemerkt es niemand. GitOps trennt die Rollen: Die CI-Pipeline baut und testet weiterhin Artefakte, das Ausrollen übernimmt der Agent in der Umgebung, der zugleich dauerhaft über die Einhaltung des Sollzustands wacht. GitOps ersetzt CI also nicht, sondern nur den Push-Schritt am Ende der Kette. Für Bestandsumgebungen hat sich der schrittweise Umstieg bewährt: erst eine unkritische Anwendung, dann der Rest, sobald Prozesse und Zuständigkeiten sitzen.
GitOps in der Praxis
Die Prinzipien lassen sich über Kubernetes hinaus auf den Netzwerkbetrieb übertragen. Bei der Mikrosegmentierung etwa entstehen Richtlinien deklarativ: Sie beschreiben, welche Workloads miteinander sprechen dürfen, und werden automatisiert durchgesetzt statt von Hand auf einzelnen Systemen gepflegt. Änderungen bleiben nachvollziehbar, Abweichungen fallen auf. Von dieser Arbeitsweise profitieren auch Umgebungen ohne Kubernetes, denn prüfbare Richtlinienpflege ist in jedem Netz ein Gewinn. In der Praxis begleiten spezialisierte Dienstleister die Einführung – von der Bewertung bestehender Deployment-Prozesse bis zum dauerhaften Betrieb automatisierter Regelwerke.
Häufige Fragen
Setzt GitOps zwingend Kubernetes voraus?
Nein, auch wenn es dort entstanden und am weitesten gereift ist. Kubernetes eignet sich besonders gut, weil es deklarativ arbeitet und Agents die Reconciliation direkt im Cluster übernehmen. Die Grundidee – versionierter Sollzustand plus automatischer Abgleich – funktioniert aber mit jedem deklarativ steuerbaren System, etwa Cloud-Ressourcen oder Netzwerkrichtlinien. Entscheidend ist allein, dass sich der Zielzustand als Code ausdrücken lässt.
Was geschieht mit manuellen Änderungen direkt an der Umgebung?
Beim nächsten Abgleich erkennt der Agent die Abweichung und stellt den in Git deklarierten Stand wieder her. Das schützt vor undokumentierten Eingriffen, verlangt jedoch Disziplin: Auch Notfallmaßnahmen müssen anschließend ins Repository zurückfließen. Bewährt haben sich definierte Break-Glass-Prozesse – die Reconciliation pausiert kurzzeitig, der Eingriff wird danach als Commit nachgezogen.
Macht GitOps die bestehende CI-Pipeline überflüssig?
Nein. Die CI-Pipeline behält ihre Aufgaben: Code kompilieren, Tests fahren, Artefakte erzeugen und in eine Registry veröffentlichen. GitOps übernimmt erst den Schritt danach, das Ausrollen in die Zielumgebung. Statt direkt in die Produktion zu schieben, aktualisiert die Pipeline eine Versionsangabe im Konfigurations-Repository; der Agent in der Umgebung wendet die Änderung an. Beide Bausteine greifen ineinander.
Welche Sicherheitsvorteile bringt das Pull-Prinzip?
Im Push-Modell hält ein externes System dauerhafte Zugangsdaten mit weitreichenden Rechten auf die Produktion – ein attraktives Angriffsziel. Im Pull-Modell 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 Angreifern der direkte Deployment-Zugang, und jede wirksame Änderung bleibt als Commit sichtbar.
Lässt sich GitOps auf Netzwerk- und Sicherheitsrichtlinien anwenden?
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 auseinander.