Pipelines und freigegebene Änderungen

Pipelines und freigegebene Änderungen

0:00 Bisher haben wir Terraform und OpenTofu vor allem von der eigenen Kommandozeile aus bedient. Das funktioniert, solange eine Person den Überblick hat. Sobald mehrere Menschen an derselben Infrastruktur arbeiten, braucht es einen festen Weg, auf dem jede Änderung geprüft, gelesen und erst dann ausgeführt wird. Genau darum geht es in diesem Modul: um eine Pipeline, die nicht einfach Befehle hintereinander abspult, sondern eine Entscheidung absichert.

0:26 Der Kerngedanke ist schlicht und trotzdem oft verletzt. Freigegeben wird ein Plan, nicht ein Branch. Und ausgeführt wird genau der Plan, den jemand gelesen hat. Wie man das technisch durchhält, sehen wir am Beispiel unserer Anwendung Saatplan.

Pipelines und freigegebene Änderungen

0:41 Der vierte Tag dreht sich um alles, was Infrastruktur im Team verlässlich macht. Nach den Tests aus dem vorigen Modul geht es nun um den Weg vom Pull Request bis zur Bereitstellung. Wir sehen uns die Stufen einer Pipeline an, klären, wie ein geprüfter Plan unverändert ausgeführt wird, sichern die Läufe gegeneinander und gegen fremden Code ab und schreiben eigene Regeln als Policy as Code.

1:02 Am Ende steht eine Übung, in der eine offene Datenbank nicht mehr durchkommt.

Die Pipeline-Stufen

1:07 Beginnen wir mit der Reihenfolge. Eine gute Pipeline erledigt zuerst alles, was eine Maschine zuverlässig beurteilen kann. Erst danach bekommt ein Mensch den Plan zu sehen — und zwar nur noch die Fragen, die wirklich ein Urteil verlangen. Dieser Fluss ist eine Art Filter, der von billig nach teuer sortiert ist. Format und Validierung kosten Sekunden und brauchen keinen Zugang zur Zielumgebung.

1:31 Tests und Scan fangen fachliche und sicherheitsrelevante Fehler ab, bevor jemand seine Zeit investiert. Dann entsteht der Plan, und zwar als Datei, die aufbewahrt wird. Das ist der Wendepunkt: Ab hier geht es nicht mehr um Code, sondern um eine konkrete Änderung an konkreter Infrastruktur. Review und Freigabe beziehen sich auf genau diese Datei, und das Apply führt sie aus. Behalten Sie die Mitte im Blick.

1:55 Der Plan als Artefakt verbindet die beiden Hälften, und an ihm hängt fast alles, was in diesem Modul noch kommt. Lesen Sie diese Tabelle von links nach rechts als Frage und Antwort. Jede Stufe stellt genau eine Frage, und jede Frage hat einen eigenen Befehl. Das ist der eigentliche Gewinn: Wenn eine Stufe rot wird, wissen Sie sofort, welche Art von Problem vorliegt.

2:17 Ein falsch eingerückter Block ist etwas anderes als ein Modul, das nicht hält, was es verspricht, und das wieder etwas anderes als eine offene Tür im Netz. Für OpenTofu gilt dasselbe unter dem Befehl tofu. Und ein Detail aus der Fußzeile verdient Aufmerksamkeit: Mit dem Schalter input gleich false bricht ein Schritt ab, statt still auf eine Eingabe zu warten, die in einer Pipeline nie kommt.

2:41 Ein Plan-Review ist kein Code-Review in anderer Verpackung. Beim Code fragen wir, ob etwas sauber geschrieben ist. Beim Plan fragen wir, ob die Welt hinterher so aussieht, wie es beabsichtigt war. Die Zusammenfassung am Ende ist der erste Prüfpunkt: Wer drei neue Ressourcen erwartet und eine Zerstörung sieht, sollte stutzig werden.

3:00 Besonders ernst sind Ressourcen, die ersetzt werden müssen. Beim Container saatplan-db heißt das, dass der Datenbankbetrieb betroffen ist. Dazu kommen Ports, Netze und Volumes, die zum Freigegebenen passen müssen. Wer hier zustimmt, übernimmt Verantwortung für die Infrastruktur. Das ist eine andere Rolle als die des Stilkritikers, und sie sollte auch so besetzt sein.

Den geprüften Plan ausführen

3:23 Ein Plan, den jemand gelesen hat, ist nur so viel wert wie die Garantie, dass später genau dieser Plan läuft. Sehen wir uns an, wie der gespeicherte Plan diese Garantie liefert — und wo sie Lücken hat. Stellen Sie sich einen unterschriebenen Kostenvoranschlag vor. Die Handwerker bauen nicht, was ihnen am Tag der Ausführung einfällt, sondern genau das, was auf dem Papier steht.

3:46 So funktioniert ein gespeicherter Plan. Terraform plan mit dem Schalter out schreibt ihn in eine Datei, und terraform apply mit dieser Datei führt ihn aus, ohne noch einmal nachzufragen. Die fehlende Rückfrage ist gewollt, denn die Freigabe ist ja schon passiert. Zwei Dinge sollten Sie mitnehmen. Diese Datei ist das eigentliche Freigabeobjekt, nicht der Pull Request. Und sie enthält die vollständige Konfiguration samt Eingabevariablen.

4:11 Damit ist sie auch ein sensibles Artefakt, das man nicht beliebig herumliegen lässt. Der Auszug zeigt das Muster in GitHub Actions: zwei getrennte Jobs, die eine Datei weiterreichen. Der erste Job initialisiert, erzeugt den Plan und packt ihn zusammen mit dem Arbeitsverzeichnis ein. Das ist wichtig, denn laut Dokumentation gehört das Verzeichnis punkt terraform dazu, und es muss im zweiten Job am selben absoluten Pfad wieder ausgepackt werden.

4:38 Das Archiv landet als Artefakt, dessen Name die Commit-Kennung trägt und das nur einen Tag aufbewahrt wird. Der zweite Job hängt vom ersten ab, läuft im Environment prod und tut fast nichts mehr: auspacken, Plan ausführen. Genau so soll es sein. Alles Entscheidende ist vorher passiert, das Apply ist nur noch Vollzug. Ein gespeicherter Plan ist kein freischwebendes Dokument. Er hängt an mehreren Dingen, und die Tabelle zeigt, wer diese Bindung jeweils überwacht.

5:05 Die Werkzeugversion, die Provider aus dem Lock File, die Identität des State und sein aktueller Stand werden von Terraform und OpenTofu selbst geprüft, mit klaren Meldungen, wenn etwas nicht passt. Interessant wird es weiter unten. Ob der Plan zum richtigen Commit gehört, muss die Pipeline selbst sicherstellen, etwa über die Kennung im Artefaktnamen.

5:26 Und bei den Zugangsdaten prüft niemand. Laut Dokumentation kann Terraform nicht erkennen, ob Plan und Apply auf dieselben Ressourcen zeigen. Diese Lücke schließen Sie nur organisatorisch, indem Sie die Umgebung fest an den Job binden. Alle vier Stolpersteine haben eine gemeinsame Wurzel: Man vertraut der Mechanik mehr, als sie leisten kann.

5:46 Ein abgelehnter Plan, der noch tagelang als Artefakt liegt, kann versehentlich doch ausgeführt werden. Darum die kurze Aufbewahrung. Wer bei der Meldung saved plan is stale einfach im Apply-Job neu plant, hat die Freigabe stillschweigend ausgehebelt, denn den neuen Plan hat niemand gesehen. Der Wechsel zwischen einem Mac und einem Linux-Runner scheitert, weil Betriebssystem und Architektur gleich sein müssen.

6:09 Und der Schalter auto-approve beim Ausführen eines gespeicherten Plans wirkt schlicht nicht. Er sieht nach einer Schutzlogik aus, die es gar nicht gibt.

Ausführungen absichern

6:18 Ein sauberer Plan nützt wenig, wenn zwei Läufe gleichzeitig am selben State arbeiten oder fremder Code an die Zugangsdaten kommt. In diesem Kapitel geht es um genau diese beiden Risiken. Diese wenigen Zeilen regeln den Verkehr. Alle Läufe, die denselben Gruppennamen tragen, stellen sich hintereinander an, statt gleichzeitig loszulegen.

6:38 Für Saatplan heißt die Gruppe nach dem State der Produktion. Entscheidend ist die zweite Zeile: Ein laufender Lauf wird nicht abgebrochen, wenn ein neuer kommt. Bei normalem Code mag es sinnvoll sein, einen veralteten Build zu stoppen. Bei einem Apply wäre das fatal, denn eine halb ausgeführte Änderung ist schlimmer als jede der beiden vollständigen.

6:58 Die dritte Zeile sorgt dafür, dass wartende Läufe nicht verworfen werden. Laut Fußzeile hält sie bis zu hundert davon in der Schlange. Damit geht keine Änderung verloren, nur weil zwei Menschen kurz nacheinander gemergt haben. Hier sehen Sie das Prinzip der gestaffelten Verteidigung. Keine einzelne Maßnahme ist für sich unüberwindbar, aber zusammen ergeben sie einen belastbaren Weg.

7:21 Der geschützte Branch sorgt dafür, dass nur geprüfte Pull Requests auf main landen. Das Environment prod verlangt eine Freigabe durch Reviewer, und die Selbstfreigabe lässt sich abschalten. Erst nach dieser Freigabe gibt es den SSH-Schlüssel für den Produktions-Host. Deployment-Branches verhindern, dass ein Lauf von irgendeinem Seitenzweig in die Produktion greift.

7:43 Und das Artefakt ist unveränderlich und kurzlebig. Falls trotz allem zwei Läufe aufeinandertreffen, bleibt der State-Lock des pg-Backends als letzte Absicherung. Er ist das Sicherheitsnetz, nicht der Plan A. Dieser Vergleich zeigt eine Grenze, die man nicht verhandeln sollte. Ein Pull Request aus einem eigenen Branch kommt von jemandem, dem das Team vertraut.

8:05 Er darf einen Plan gegen die Testumgebung erzeugen und nach Freigabe an die Secrets. Ein Pull Request aus einem Fork kann von jedem stammen. Deshalb bekommt er außer einem nur lesenden Token keine Geheimnisse, und es bleiben Format, Validierung und Tests mit Mocks. Das klingt streng, ist aber die einzige vernünftige Haltung. Besonders gefährlich ist der Auslöser pull request target in Kombination mit einem Checkout des fremden Codes.

8:30 Damit liefe fremder Code mit den Rechten des Repositorys. Diese Tür bleibt zu. Viele unterschätzen, was schon ein Plan tut. Er ist kein harmloser Blick ins Archiv, sondern führt Provider-Code aus und braucht echten Zugang zum Ziel. Wer Pläne erzeugen darf, hält also bereits einen Schlüssel in der Hand. Bei Cloud-Providern gibt es dafür eine elegante Lösung: OIDC ersetzt langlebige Schlüssel durch kurzlebige Token, die nur für einen Lauf gelten.

8:57 Der Docker-Provider, den Saatplan nutzt, spricht dagegen SSH. Hier bleibt ein Deploy-Schlüssel, und der sollte so eng wie möglich auf ein Environment begrenzt sein. Interne Hosts und die State-Datenbank erreicht ohnehin nur ein Runner im eigenen Netz. Ein solcher Runner gehört nie an ein öffentliches Repository.

Standards und Policy as Code

9:16 Bis hierher haben Menschen über Pläne entschieden. Manche Regeln sind aber so klar, dass niemand sie jedes Mal neu prüfen sollte. Die schreiben wir als Code auf und lassen sie an einem festen Punkt entscheiden. Die drei Schichten beantworten die Frage, wann eine Regel am besten zuschlägt. Ganz oben steht die Konfiguration.

9:35 Hier greifen Variablen-Validierung und Checkov auf den HCL-Dateien, also früh und schnell, aber ohne zu wissen, was am Ende tatsächlich passiert. Die mittlere Schicht ist der Plan als JSON. Er kennt die konkreten Werte nach dem Auflösen aller Variablen und Module, und genau deshalb ist er für viele Regeln der aussagekräftigste Prüfpunkt.

9:55 Unten liegt die Plattform selbst, die manches verweigert, ganz gleich, mit welchem Werkzeug man kommt. Eine gute Regel sitzt in der Schicht, in der sie die nötige Information hat. Nicht jede gehört ganz nach oben. Diese Regel ist in Rego geschrieben, der Sprache von OPA, und wird hier mit conftest ausgeführt. Die Logik ist schnell erzählt: Sie geht durch alle geplanten Änderungen, sucht den Docker-Container namens saatplan-db und schlägt Alarm, sobald er nach der Änderung auch nur einen Port veröffentlicht.

10:26 Die Eingabe ist der Plan als JSON, den terraform show erzeugt. Damit prüft die Regel nicht, was im Code steht, sondern was tatsächlich passieren würde. Bemerkenswert ist der Hinweis in der Fußzeile. Für den Docker-Provider bringt Checkov keine eigenen Prüfungen mit. Solche Regeln sind also Eigenbau, und genau dafür ist Policy as Code gedacht.

10:46 Die Tabelle trennt die Werkzeuge nach einer praktischen Frage: Wer betreibt die Prüfung? Sentinel und OPA laufen in HCP Terraform und in der Enterprise-Variante, dort kennen sie abgestufte Entscheidungen von bloßem Hinweis bis zur harten Pflicht. Conftest und Checkov laufen in Ihrer eigenen Pipeline, und dort ist die Logik einfacher: Eine verletzte Regel bricht ab, eine Warnung meldet nur.

11:10 Welcher Weg passt, hängt weniger von der Regelsprache ab als davon, wo Ihre Läufe überhaupt stattfinden. Wer HCP Terraform nicht nutzt, braucht dessen Policy-Funktionen nicht. Und wer es im Free-Tarif nutzt, sollte die Grenze aus der Fußzeile kennen: ein Policy Set mit fünf Policies. Das ist vielleicht die wichtigste Folie des Kapitels, weil sie über die Lebensdauer jeder Regel entscheidet.

11:33 Eine Prüfung ohne geregelte Ausnahme überlebt nur bis zu dem Tag, an dem sie einmal wirklich im Weg steht. Dann wird sie abgeschaltet, und zwar meistens ganz. Die Werkzeuge bieten dafür eigene Mittel: conftest kennt Ausnahme-Regeln, Checkov einen Kommentar zum Überspringen, der eine Begründung im Code verlangt. In HCP Terraform darf nur übersteuern, wer das Recht dazu hat, und der Lauf hält es fest. Der entscheidende Punkt ist aber organisatorisch.

12:00 Jede Ausnahme bekommt ein Ablaufdatum und geht durch das Review wie jede andere Änderung. So bleibt sie sichtbar, statt still zur neuen Regel zu werden.

Übung

12:09 Jetzt setzen wir alles zusammen. Die Übung hat ein einfaches, gut überprüfbares Ziel: Eine offene Datenbank soll es nicht mehr durch die Pipeline schaffen, ein korrekter Plan dagegen schon — aber erst nach Freigabe. Bei dieser Aufgabe üben Sie, eine Infrastruktur-Pipeline so zu schneiden, dass die Prüfungen tatsächlich blockieren und am Ende nur ein freigegebener, gespeicherter Plan läuft.

12:32 Es geht also weniger um einzelne YAML-Zeilen als um die Architektur der Absicherung. Erfolgreich sind Sie, wenn zwei Dinge sichtbar werden. Ein Pull Request, der der Datenbank saatplan-db den Port 5432 öffnet, scheitert an Ihrer Policy. Und ein korrekter Plan wartet geduldig auf die Freigabe und läuft danach unverändert durch.

12:52 Falls Ihnen kein Runner im eigenen Netz zur Verfügung steht, ist das kein Hindernis: Richten Sie die Pipeline gegen den lokalen Docker-Host und die Umgebung test ein. Die Schritte folgen dem Weg, den wir im Modul gegangen sind. Zuerst entsteht der Prüf-Job mit allem, was eine Maschine beurteilen kann, einschließlich der Regel für die Datenbank.

13:12 Dann wird der Plan zum Artefakt, eindeutig benannt und für Reviewer sichtbar in der Zusammenfassung. Der Apply-Job bekommt die Freigabe als Bedingung und führt genau diesen Plan aus. Danach testen Sie die Verkehrsregeln mit zwei schnell aufeinanderfolgenden Läufen und weisen mit einem bewusst falschen Pull Request die Blockade nach.

13:30 Lohnend ist auch der Zusatz aus der Fußzeile: Lassen Sie einen freigegebenen Plan liegen, ändern Sie die Umgebung und beobachten Sie, wie er als veraltet abgelehnt wird. Was passiert, wenn trotz allem ein Lauf schiefgeht, klärt das nächste Modul.