Bildquelle: Pexels / cookiecutter / https://www.pexels.com/photo/network-rack-17323801/
Ohne Umgang mit Secrets, Datenbanken und Notfällen bleibt GitOps ein Inselprojekt
GitOps klingt für viele Teams zunächst angenehm eindeutig: Der gewünschte Zustand liegt deklarativ in Git, Änderungen sind versioniert, ein Controller zieht sie automatisiert in die Zielumgebung und gleicht Abweichungen kontinuierlich wieder an. Genau so beschreiben es die OpenGitOps-Prinzipien. In der Praxis entsteht die eigentliche Reife aber nicht dort, wo ein Cluster sauber aus einem Repository gebaut wird, sondern dort, wo Betriebsrealität auf diese Logik trifft.
Denn kaum ein produktives System besteht nur aus leicht austauschbaren Kubernetes-Ressourcen. Früher oder später geraten Teams an drei Zonen, in denen GitOps schnell unscharf wird: Secrets, Datenbanken und Notfalländerungen. Wer an diesen Stellen mit Sonderwegen, stillen Ausnahmen oder manuellen Workarounds arbeitet, hat zwar vielleicht GitOps-Tools im Einsatz, aber noch kein belastbares GitOps-Betriebsmodell.
Das ist kein akademisches Problem. Gerade in Plattform- und Produktteams zeigt sich oft derselbe Verlauf: Der erste Rollout mit Argo CD oder Flux funktioniert, Deployments werden reproduzierbarer und Pull Requests ersetzen manche Tickets. Wenige Monate später bremsen aber andere Fragen: Wie laufen Secret-Rotationen, ohne dass sie zufällig mit einem App-Sync gekoppelt werden? Wer verantwortet Schemaänderungen, die sich nicht wie ein Container-Image zurückrollen lassen? Und was passiert, wenn im Incident jemand per Hand eingreifen muss, der Controller diese Änderung aber beim nächsten Reconcile sofort wieder überschreibt?
GitOps scheitert selten am Repository, sondern an der Betriebsgrenze
Die eigentliche Stärke von GitOps liegt in Nachvollziehbarkeit, Wiederholbarkeit und kontrollierter Automatisierung. Das funktioniert hervorragend für deklarative Infrastruktur- und Applikationszustände. Schwächer wird das Modell dort, wo Zustände außerhalb normaler YAML-Objekte entstehen oder wo Änderungen zeitkritisch und zustandsbehaftet sind.
Genau deshalb ist es zu kurz gedacht, GitOps nur als Deploy-Muster für Kubernetes zu behandeln. In produktiven Umgebungen muss GitOps ein Betriebsrahmen sein. Er braucht Regeln dafür, welche Artefakte wirklich in Git landen, welche bewusst außerhalb des Repositories gesteuert werden, welche Ausnahmen zulässig sind und wie ein manueller Eingriff wieder in den Sollzustand zurückgeführt wird. Ohne diese Regeln wächst um das eigentliche GitOps-Setup herum ein Schattenbetrieb.
Secrets gehören nicht in einen halbgaren Sonderpfad
Bei Secrets zeigt sich das besonders deutlich. Viele Teams starten mit dem naheliegenden Gedanken, auch geheime Werte irgendwie in denselben GitOps-Fluss zu pressen wie Deployments, ConfigMaps oder Policies. Argo CD warnt in seiner Dokumentation jedoch ausdrücklich davor, Secrets erst während der Manifest-Generierung im Tool selbst einzuspritzen. Der empfohlene Weg ist vielmehr, Secrets auf dem Ziel-Cluster zu verwalten, etwa über Operatoren wie External Secrets oder Sealed Secrets.
Der Grund ist operativ wichtig: Sobald Secret-Änderungen eng an den normalen App-Sync gekoppelt sind, steigen Risiko und Nebenwirkungen. Eine Passwortrotation kann dann unbeabsichtigt mit einem Release zusammenfallen. Gleichzeitig vergrößert sich die Angriffsfläche, wenn das GitOps-System selbst tiefen Zugriff auf Klartext-Geheimnisse braucht oder gerenderte Manifeste mit sensiblen Inhalten zwischenspeichert.
Für Teams heißt das: GitOps braucht eine klare Secret-Grenze. Git darf die Referenz, Policy und gewünschte Einbindung beschreiben. Der eigentliche geheime Wert sollte aber über einen dafür geeigneten Betriebsweg kommen. Wer diese Trennung sauber zieht, verbessert nicht nur die Sicherheit, sondern reduziert auch Kopplung im Release-Prozess.
Datenbanken folgen einem anderen Lebenszyklus als Deployments
Noch sichtbarer wird die Lücke bei Datenbanken. Anwendungscode lässt sich in vielen Fällen neu ausrollen, replizieren oder im Zweifel auf einen vorherigen Stand zurücksetzen. Bei Schemaänderungen, Datenmigrationen und abhängigen Jobs ist die Lage komplexer. Eine einmal ausgeführte Migration verändert reale Datenbestände, oft inklusive Zeitfenstern, Locking-Verhalten und Rückfallkosten.
GitOps-Werkzeuge helfen hier durchaus, aber nicht als magischer Vollersatz. Argo CD unterstützt mit Sync-Phasen, Hooks und Waves eine definierte Reihenfolge für vorbereitende Jobs, eigentliche Rollouts und nachgelagerte Prüfungen. Das ist nützlich, um Migrationen kontrollierter einzubetten. Es löst aber nicht die Managementfrage, wer Datenbankänderungen fachlich freigibt, wie Rückwärtskompatibilität abgesichert wird, welche Rollback-Grenzen gelten und wann ein Deployment auf einen manuellen Halt warten muss.
Teams geraten hier oft in einen gefährlichen Zwischenzustand: Die Applikation läuft formal unter GitOps, die Datenbankänderungen werden aber weiter über Chat, Shell-Zugänge oder Einmal-Skripte koordiniert. Genau dann entstehen die bekannten Brüche zwischen Plattform, Entwicklung und Betrieb. GitOps wirkt nach außen konsistent, intern leben jedoch zwei unverbundene Änderungsregime.
Notfalländerungen brauchen einen ehrlichen Break-Glass-Pfad
Der dritte Bruchpunkt sind Notfälle. Die Flux-Dokumentation beschreibt offen, dass manuelle kubectl-Änderungen an verwalteten Objekten bei der nächsten Reconciliation wieder überschrieben werden. Genau das ist im Normalfall sogar erwünscht: Drift soll verschwinden. Im Incident kann dieselbe Eigenschaft aber zum Problem werden, wenn ein Team in Minuten handeln muss und der Controller den manuellen Hotfix direkt wieder zurückdreht.
Die Antwort darauf ist nicht, GitOps im Ernstfall still auszuschalten und später zu hoffen, dass schon nichts auseinanderläuft. Belastbarer ist ein expliziter Break-Glass-Pfad. Dazu gehören definierte Rollen, zulässige Eingriffe, ein Zeitfenster für die Ausnahme und vor allem die Pflicht, jede Notfalländerung zügig wieder in Git nachzuziehen oder bewusst zurückzubauen. Sonst bleibt nach dem Incident ein Zustand zurück, der weder sauber dokumentiert noch reproduzierbar ist.
Für Plattformteams ist das eine Führungsaufgabe. Ein Incident-Runbook muss beschreiben, wann Drift toleriert werden darf, wer sie autorisiert und wie die Rückkehr in den deklarativen Sollzustand überprüft wird. Erst dann wird aus „manchmal greifen wir eben manuell ein“ ein tragfähiger Betriebsmechanismus.
Was ein belastbares GitOps-Betriebsmodell ausmacht
Ein reifes Modell beantwortet deshalb mehr als nur die Frage, welches Tool genutzt wird. Es legt fest, welche Klassen von Änderungen komplett deklarativ laufen, welche über flankierende Operatoren oder Jobs eingebunden werden und welche Sonderpfade unter strenger Kontrolle bleiben. Vor allem verbindet es Entwicklung, Plattform und Betrieb über dieselben Regeln.
- Secrets trennen: Referenzen und Policies dürfen deklarativ sein, geheime Werte selbst brauchen einen sicheren Zielsystem-Pfad.
- Datenbankänderungen als eigenes Change-Objekt behandeln: inklusive Reihenfolge, Freigabe, Rückfallgrenzen und Verantwortlichkeiten.
- Break-Glass definieren: manuelle Eingriffe dürfen kein stiller Privatprozess einzelner Engineers sein.
- Drift bewusst managen: nicht jede Abweichung ist ein Fehler, aber jede tolerierte Abweichung braucht Ablaufdatum und Rückführung.
- Ownership klären: Plattform, Applikation und Datenbank dürfen nicht in getrennten Betriebslogiken verharren.
- Reconcile-Verhalten verstehen: Controller-Automatik ist nur dann ein Vorteil, wenn alle Beteiligten ihre Konsequenzen im Alltag kennen.
Fazit
GitOps wird nicht dadurch erwachsen, dass Deployments aus Git kommen. Reif wird es erst dann, wenn auch die unbequemen Randzonen des Betriebs sauber eingeordnet sind. Secrets, Datenbanken und Notfälle sind keine lästigen Ausnahmen, sondern die Stellen, an denen sich entscheidet, ob GitOps ein tragfähiges Betriebsmodell oder nur ein sauber verpackter Deploy-Mechanismus ist.
Für IT-Operations, Plattform-Engineering und DevOps-Verantwortliche lohnt sich deshalb ein nüchterner Blick auf die eigenen Ausnahmen. Wenn genau dort noch Mail, Shell, Chat und Bauchgefühl dominieren, ist das kein kleiner Schönheitsfehler. Es ist das Signal, dass GitOps zwar technisch eingeführt wurde, operativ aber noch als Inselprojekt läuft.
