Eine von Hand aufgebaute Umgebung ist ein Unikat: schwer zu reproduzieren, und nach zwei Jahren kann niemand mehr begründen, warum eine bestimmte Firewallregel existiert. Infrastructure as Code (IaC) beendet dieses Modell.
Infrastruktur wird stattdessen in Konfigurationsdateien beschrieben und automatisiert erzeugt – mit den Methoden, die sich in der Softwareentwicklung bewährt haben, allen voran Versionierung und Review. Durchgesetzt hat sich der Ansatz mit der Cloud; seine Wirkung reicht inzwischen weit darüber hinaus, bis in Netzwerk- und Sicherheitsrichtlinien hinein.
Was ist Infrastructure as Code?
Infrastructure as Code bezeichnet die Praxis, Infrastruktur in maschinenlesbaren Dateien zu definieren und über Werkzeuge automatisiert bereitzustellen. Das umfasst virtuelle Maschinen und Kubernetes-Cluster ebenso wie Netzwerke, Firewallregeln oder DNS-Einträge. Die Definitionen liegen in einem Versionskontrollsystem und durchlaufen vor jeder Änderung ein Review. Aus derselben Beschreibung entstehen identische Umgebungen – für Test wie für Produktion. Infrastruktur wird damit prüfbar wie Quellcode: Jede Änderung trägt Autor und Zeitstempel, fehlerhafte Stände lassen sich auf einen früheren Zustand zurücksetzen. Der Code wird zugleich zur verlässlichen Dokumentation, denn er beschreibt keine Absicht von gestern – er ist die Quelle, aus der die Umgebung tatsächlich entstanden ist.
Funktionsweise
- Deklarativ oder imperativ: Deklarative Werkzeuge beschreiben den Zielzustand; die nötigen Schritte ermittelt das Werkzeug selbst. Imperative Ansätze legen die Schritte explizit fest, etwa als Skriptfolge. Für Infrastruktur haben sich deklarative Ansätze weitgehend durchgesetzt, weil sie idempotent arbeiten: Mehrfache Ausführung führt zum selben Ergebnis.
- Versionierung als Fundament: Jede Änderung läuft als Pull Request mit Review. Die Historie hält fest, wer was wann geändert hat – und warum.
- Plan vor Ausführung: Gängige Werkzeuge zeigen vor der Anwendung, welche Ressourcen entstehen, sich ändern oder wegfallen. Dieser Plan ist die letzte Kontrollinstanz vor dem Eingriff in reale Umgebungen.
- Drift-Erkennung: Weicht die reale Umgebung von der Definition ab – etwa durch manuelle Änderungen in einer Cloud-Konsole – macht der Abgleich das sichtbar. Drift wird zurückgerollt oder bewusst in den Code übernommen.
- Security-Scans für Templates: Spezialisierte Scanner prüfen IaC-Definitionen vor dem Rollout auf Fehlkonfigurationen, etwa offene Netzwerkzugriffe oder zu weit gefasste Berechtigungen. Fehler werden gestoppt, bevor sie eine Umgebung erreichen.
Warum IaC wichtig ist
- Reproduzierbarkeit: Umgebungen entstehen aus Code statt aus Erinnerung. Eine zusätzliche Testumgebung oder ein neuer Standort wird zur Routineaufgabe statt zum Projekt.
- Weniger manuelle Fehler: Automatisierte Abläufe vermeiden Tippfehler und vergessene Schritte, die bei Handarbeit zwangsläufig vorkommen.
- Nachvollziehbarkeit für Audits: Die Versionshistorie beantwortet Prüferfragen direkt – wer hat die Änderung veranlasst, wer hat sie freigegeben, wann wurde sie wirksam?
- Schnelle Wiederherstellung: Nach einem Ausfall wird die Umgebung aus der Definition neu aufgebaut statt aus Backups und Gedächtnisprotokollen rekonstruiert.
- Sicherheit vor dem Rollout: Scans prüfen Konfigurationen, bevor sie live gehen – früher und verlässlicher als jede nachträgliche Kontrolle laufender Systeme.
- Basis für Weiteres: GitOps und automatisierte Compliance-Prüfungen setzen auf sauber definierter Infrastruktur auf.
Typische Szenarien
Der häufigste Einstieg ist die Cloud-Migration: Neue Umgebungen werden von Beginn an als Code aufgebaut, weil das Zusammenklicken hunderter Ressourcen weder skaliert noch dokumentierbar ist. Ein zweites Szenario ist der Gleichlauf mehrerer Umgebungen: Test und Produktion sollen sich nur in definierten Parametern unterscheiden, damit Testergebnisse aussagekräftig bleiben. Drittens Disaster Recovery: Der Wiederaufbau am Ausweichstandort gelingt in verlässlicher Zeit, wenn die komplette Umgebung als Code vorliegt. Und schließlich das Netzwerk selbst: Firewallregeln und Segmentierungsrichtlinien gewinnen als Code Review-Pflicht und Historie – gerade weil manuelle Regeländerungen erfahrungsgemäß fehleranfällig sind. Auch bei Übernahmen und Ausgründungen zahlt sich der Ansatz aus, weil sich definierte Umgebungen sauber duplizieren oder herauslösen lassen.
Abgrenzung: IaC und Konfigurationsmanagement
Beide Disziplinen automatisieren, setzen aber an unterschiedlichen Punkten an. IaC provisioniert Ressourcen: Es erzeugt Netze, virtuelle Maschinen, Load Balancer oder Datenbanken und verwaltet deren Lebenszyklus. Konfigurationsmanagement richtet Systeme ein, die bereits existieren: Es installiert Software und hält Konfigurationsdateien konsistent. In klassischen Umgebungen ergänzen sich beide – IaC stellt die Maschine bereit, Konfigurationsmanagement macht sie betriebsbereit. Container verschieben diese Grenze, weil die Konfiguration ins Image wandert und Systeme unveränderlich betrieben werden. Die Unterscheidung bleibt dennoch wichtig: Wer beide Aufgaben mit demselben Werkzeug erzwingt, landet häufig bei schwer wartbaren Konstrukten.
IaC im Netzwerkbetrieb
Den größten Hebel für sichere Unternehmensnetzwerke haben IaC-Prinzipien bei Konnektivität und Segmentierung. Anbindungen an Cloud-Umgebungen lassen sich über Cloud Connectivity reproduzierbar und nachvollziehbar aufbauen statt als gewachsene Einzelkonfiguration. Segmentierungsrichtlinien werden als deklarative Policies gepflegt: Sie beschreiben erlaubte Kommunikation, die Durchsetzung erfolgt automatisiert, und jede Änderung bleibt dokumentiert. Den laufenden Betrieb – von der Pflege der Definitionen bis zur Kontrolle auf Abweichungen – übernehmen in der Praxis oft Managed-Service-Provider. Netzwerkänderungen verlieren so ihren Schrecken, weil sie vor dem Rollout geprüft werden und umkehrbar bleiben.
Häufige Fragen
Worin unterscheiden sich deklaratives und imperatives IaC?
Deklarative Ansätze beschreiben den gewünschten Endzustand; das Werkzeug berechnet die nötigen Schritte und gleicht wiederholt gegen die Realität ab. Imperative Ansätze legen die Schritte selbst fest, etwa als Skript, das Ressourcen in fester Reihenfolge anlegt. Für Infrastruktur hat sich deklarativ durchgesetzt, weil Läufe idempotent sind und der Code zugleich den Sollzustand dokumentiert.
Was ist Konfigurationsdrift und wie geht man damit um?
Drift entsteht, wenn die reale Umgebung vom definierten Code abweicht – meist durch manuelle Eingriffe in Konsolen oder auf Systemen. Umgebungen werden dadurch unvorhersehbar, die Dokumentation verliert ihren Wert. Dagegen helfen regelmäßige automatische Abgleiche, die Abweichungen melden, klare Regeln für Notfalleingriffe samt Rückführung in den Code sowie restriktive Rechte für direkte Änderungen an produktiven Ressourcen.
Wie lässt sich IaC absichern?
Infrastruktur-Code verdient dieselbe Behandlung wie Anwendungscode: verpflichtende Reviews, Scans auf Fehlkonfigurationen vor jedem Rollout und Secret-Prüfungen, damit keine Zugangsdaten in Templates landen. Die ausführende Pipeline erhält eng begrenzte Rechte, getrennt je Umgebung. Der Zustand der Werkzeuge – etwa State-Dateien – enthält sensible Daten und gehört verschlüsselt und zugriffsbeschränkt abgelegt.
Ist IaC nur für Cloud-Umgebungen relevant?
Nein. Der Ansatz stammt aus der Cloud, wirkt aber überall dort, wo sich Ressourcen über Schnittstellen steuern lassen. Auch im Rechenzentrum lassen sich Netzwerkkonfigurationen, Firewallregeln und Segmentierungsrichtlinien als Code pflegen. Gerade Sicherheitsrichtlinien gewinnen dadurch Review-Pflicht und Historie – etwas, das manuelle Regelpflege auf einzelnen Geräten nicht leisten kann.
Was trennt IaC vom Konfigurationsmanagement?
IaC erzeugt und verwaltet Ressourcen: Netze, virtuelle Maschinen oder Cluster entstehen aus deklarativen Definitionen. Konfigurationsmanagement kümmert sich um das Innenleben bereits vorhandener Systeme, etwa installierte Software und Dienste. In klassischen Umgebungen ergänzen sich beide. In Container-Plattformen verliert Konfigurationsmanagement an Gewicht, weil Konfiguration ins Image wandert und Systeme unveränderlich betrieben werden.