Secrets und sensible Daten

Secrets und sensible Daten

0:00 Willkommen zu Modul sieben. Bis hierher haben wir Ressourcen modelliert, Module gebaut und den State in ein gemeinsames Backend gelegt. Damit ist eine Frage unausweichlich geworden, die viele Teams erst stellen, wenn es zu spät ist: Wo liegen eigentlich unsere Geheimnisse? Das Datenbankpasswort von Saatplan, die Zugänge zu den Docker-Hosts, der Schlüssel zur Registry. In diesem Modul verfolgen wir diese Werte auf ihrem Weg durch die Konfiguration.

0:25 Wir trennen Berechtigungen, sehen uns an, was das Schlüsselwort sensitive leistet und was nicht, lernen Werte kennen, die gar nicht erst gespeichert werden, und verschlüsseln mit OpenTofu den State selbst. Am Ende holen Sie das Passwort in einer Übung tatsächlich aus dem State heraus.

Secrets und sensible Daten

0:42 Der dritte Tag dreht sich um alles, was ein Projekt erwachsen macht: Geheimnisse, mehrere Umgebungen und vorhandene Infrastruktur. Wir beginnen mit den Geheimnissen, und der Satz auf dieser Folie gibt die Richtung vor. Sicher ist ein Passwort erst, wenn Sie jede Stelle kennen, an der es liegt. Und die beste Stelle ist die, an der es gar nicht erst ankommt. Genau dorthin arbeiten wir uns in diesem Modul Schritt für Schritt vor.

Berechtigungen trennen

1:07 Bevor wir über einzelne Passwörter sprechen, eine Stufe darüber: über Zugänge. Denn das beste Geheimnismanagement nützt wenig, wenn am Ende ein einziger Schlüssel jede Tür öffnet. Denken Sie an ein Gewächshaus der Gärtnerei. Wer die Bewässerung einstellt, braucht keinen Schlüssel zur Kasse, und wer die Lieferscheine prüft, muss nicht ins Heizungslager.

1:29 Bei Terraform und OpenTofu ist es genauso. Ein Lauf braucht drei verschiedene Zugänge: einen zum Backend mit dem State, einen zum Zielsystem, das der Provider steuert, und die Identität der Umgebung, in der der Lauf überhaupt stattfindet. Das sind drei Rollen, und sie verdienen drei Schlüssel. Der Gewinn ist schlicht, aber entscheidend: Fließt einer davon ab, ist der Schaden begrenzt.

1:51 Wer alles mit einem einzigen Zugang erledigt, spart sich heute etwas Konfiguration und zahlt im Ernstfall mit dem ganzen Betrieb. Die Tabelle übersetzt das Prinzip auf Saatplan. Lesen Sie sie von rechts: In der letzten Spalte steht jeweils das Minimum, und jedes Wort darin ist eine bewusste Einschränkung. Das Backend sieht nur die eine Datenbank für den State. Auf den Testhost darf das Team, auf den Produktionshost nur die Pipeline.

2:16 Die Registry wird nur gelesen, und der Secret Store gibt kurzlebige Tokens heraus statt dauerhafter Schlüssel. Achten Sie besonders auf die Fußzeile. Wer den Docker-Daemon steuern darf, hat auf dem Host praktisch Root-Rechte. Der Zugang zu docker-prod ist deshalb der wertvollste in der ganzen Liste, und er gehört in so wenige Hände wie möglich.

2:37 Der erste Stolperstein ist der bequemste: ein Admin-Zugang für alles. Dann kann jeder, der nur mal in den State schauen will, auch produktiv ausrollen. Der zweite passiert oft ganz am Anfang eines Projekts. Die Verbindungszeichenfolge zum Backend landet samt Passwort im backend-Block und damit im Repository saatplan-infra, für immer in der Historie.

2:57 Der dritte ist tückisch, weil er nach Sicherheit aussieht: Der Secret Store ist sauber angebunden, aber sein Wert wandert über ein ganz normales Argument doch in den State. Und der vierte ist Gewohnheit: langlebige Schlüssel in CI-Variablen, obwohl die Plattform längst kurzlebige Zugangsdaten anbieten würde.

sensitive und was im State bleibt

3:15 Jetzt zum Werkzeug, zu dem fast jeder zuerst greift, wenn ein Passwort in der Konfiguration auftaucht. Es tut, was es verspricht. Es verspricht nur weniger, als viele glauben. Wer sensitive auf true setzt, an einer Variable oder einem Output, sorgt dafür, dass der Wert in der Ausgabe von plan und apply nicht erscheint. Das ist ansteckend im guten Sinn: Jeder Ausdruck, der den Wert verwendet, wird ebenfalls als sensibel behandelt. Aber vergleichen Sie es mit Milchglas an einer Bürotür.

3:46 Von außen sieht man nichts, doch wer den Schlüssel hat, geht hinein und liest alles. Terraform und OpenTofu schreiben sensible Werte nämlich weiterhin in den State und in die Plan-Datei. Maskiert ist eben nicht verschlüsselt. Das macht sensitive nicht wertlos, es hält Passwörter aus Logs und Bildschirmen heraus. Es ist nur kein Tresor.

4:07 So sieht die Ausgangslage aus, und sie wirkt auf den ersten Blick vorbildlich. Die Variable für das Datenbankpasswort ist als sensibel markiert, im Plan erscheint sie maskiert. Dann reicht der Container saatplan-db das Passwort als Umgebungsvariable an Postgres weiter, und genau dort liegt das Problem. env ist für den Docker-Provider ein ganz normales Argument. Was dort steht, speichert er vollständig im State, Passwort inklusive.

4:32 Die Markierung an der Variable ändert daran nichts. Merken Sie sich dieses Muster, denn es ist typisch: Der Schutz sitzt am Eingang, und der Wert verlässt das Haus durch die Hintertür. Genau diese Konfiguration bauen wir später in der Übung um. Diese Tabelle ist eine kleine Landkarte der Fundstellen, und sie ist länger, als die meisten erwarten. Der State im Backend ist die offensichtliche.

4:56 Dazu kommt die gespeicherte Plan-Datei, die neben geplanten Attributen auch Variablenwerte enthält. Ein Output, den Sie als JSON oder roh abfragen, erscheint im Klartext, und landet er im Pipeline-Log, liest ihn jeder mit Zugriff aufs Log. Gespeicherte Pläne zwischen Jobs werden zu CI-Artefakten. Und ein lokaler State ist schlicht eine Textdatei auf einem Laptop.

5:17 Die Logik der rechten Spalte ist überall dieselbe: Wenn sich die Speicherung nicht vermeiden lässt, bleiben nur wenige Leser und eine kurze Lebensdauer.

Ephemeral Values und Write-only Arguments

5:27 Wenn jede gespeicherte Kopie ein Risiko ist, liegt die nächste Frage nahe: Lässt sich das Speichern ganz vermeiden? Neuere Versionen beider Werkzeuge haben darauf eine Antwort. Ephemeral heißt flüchtig, und genau das ist gemeint. Ein solcher Wert existiert nur während eines einzigen Laufs und wird weder in den State noch in die Plan-Datei geschrieben.

5:48 Stellen Sie sich einen Boten vor, der einen Umschlag übergibt und keine Kopie behält. Flüchtig können Variablen und Outputs sein, wenn Sie sie entsprechend markieren, und es gibt eigene Ephemeral Resources, die etwa einen Wert aus einem Secret Store holen. Damit so ein Wert in eine dauerhaft verwaltete Ressource gelangt, braucht es Write-only Arguments. Die nimmt der Provider entgegen, speichert sie aber nicht.

6:11 Das ist der eigentliche Fortschritt: Das Geheimnis wird benutzt, ohne Spuren zu hinterlassen. Bei dieser Tabelle lohnt der Blick auf das Muster, nicht auf jede Zahl. Terraform hat die flüchtigen Bausteine mit Version 1.10 eingeführt und die Write-only Arguments mit 1.11 nachgezogen. OpenTofu liefert alles gemeinsam ab Version 1.11.

6:32 Wer also mit beiden Werkzeugen arbeitet, plant am einfachsten mit 1.11 als Untergrenze. Die Fußzeile enthält aber die eigentlich wichtige Einschränkung. Write-only ist keine Sprachfunktion, die überall automatisch greift. Der Provider muss solche Argumente ausdrücklich anbieten, etwa ein Write-only-Passwort samt eigener Versionsnummer bei einer Cloud-Datenbank.

6:54 Ob Ihr Provider das kann, entscheidet also, wie weit Sie mit diesem Ansatz kommen. Und hier zeigt sich, warum das so wichtig ist. Links steht unser Docker-Provider in Version 4.6, rechts eine typische Cloud-Datenbank. In der Cloud setzen Sie das Passwort über ein Write-only-Argument, es bleibt außerhalb des State, und rotiert wird, indem Sie eine Versionsnummer erhöhen.

7:17 Der Docker-Provider bietet kein einziges Write-only-Argument an. Flüchtige Werte nimmt er nur im Provider-Block an, etwa für den Zugang zur Registry. Für das Datenbankpasswort heißt das: Über env landet es zwangsläufig im State. Der Ausweg in der letzten Zeile ist eher handwerklich als elegant, aber er funktioniert. Terraform erfährt nur, wo das Passwort liegt, nicht, wie es lautet.

7:41 Das ist dieser Ausweg in Code. Statt des Passworts selbst bekommt Postgres nur einen Dateipfad genannt. Das offizielle postgres-Image kennt diese Variante und liest das Passwort beim Initialisieren aus der Datei. Die Datei liegt auf dem Host und wird schreibgeschützt in den Container eingebunden. Im State steht damit nur noch ein Pfad, und ein Pfad verrät nichts.

8:02 Beachten Sie die Arbeitsteilung, die die Fußzeile beschreibt: Die Datei legt der Betrieb aus dem Secret Store ab, nicht Terraform. Das ist eine bewusste Grenze. Infrastructure as Code beschreibt hier die Struktur, und das Geheimnis selbst bleibt außerhalb seiner Reichweite. Vier Fallen, und drei davon zeigen, dass die neuen Bausteine Disziplin verlangen.

8:23 Wer eine flüchtige Variable an env übergibt, bekommt einen Fehler, denn normale Argumente lehnen flüchtige Werte ab. Das ist ärgerlich, aber ehrlich. Wer einen Write-only-Wert ändert und die Versionsnummer vergisst, erlebt das Gegenteil: Es wird schlicht keine Änderung geplant. Ein flüchtig erzeugtes Zufallspasswort ohne Ablage im Secret Store ist nach dem Lauf verloren, denn niemand kennt es mehr. Und die letzte Falle betrifft Postgres selbst.

8:49 Liegt auf dem Volume saatplan-daten schon eine Datenbank, ändert eine neue Passwortdatei daran nichts. Das Image liest sie nur beim allerersten Initialisieren.

State- und Plan-Verschlüsselung in OpenTofu

8:59 Manches Geheimnis lässt sich nicht aus dem State heraushalten. Dann bleibt der zweitbeste Weg: den State selbst unlesbar machen. Und hier gehen die beiden Werkzeuge erstmals deutlich getrennte Wege. Seit Version 1.7 verschlüsselt OpenTofu State und Plan-Dateien, bevor sie auf die Platte oder ins Backend wandern. Konfiguriert wird das in einem encryption-Block innerhalb des terraform-Blocks oder über eine Umgebungsvariable.

9:24 Der Unterschied zur Datenbank, die ihre Platten verschlüsselt, ist grundsätzlich. Dort schützt der Betreiber den Speicher, hier schützt das Werkzeug den Inhalt, und zwar bevor er das eigene Haus verlässt. Terraform kennt keinen solchen Block. Dort verschlüsselt allenfalls das Backend selbst. Für Teams, die zwischen beiden Werkzeugen wählen, ist das eines der handfestesten Argumente, und wir kommen in Modul dreizehn beim Vergleich noch einmal darauf zurück.

9:50 Der Aufbau folgt einer klaren Kette. Ein Key Provider erzeugt den Schlüssel, hier aus einer Passphrase, die mindestens sechzehn Zeichen lang sein muss. Eine Methode legt das Verfahren fest, hier AES-GCM, und bekommt den Schlüssel übergeben. Zum Schluss sagen der state- und der plan-Block, welche Methode jeweils gilt. Das Schöne an dieser Trennung: Wollen Sie später auf einen Schlüsseldienst umsteigen, tauschen Sie nur das erste Glied aus.

10:15 Die Fußzeile nennt die Möglichkeiten, von den Diensten der großen Cloud-Anbieter bis zu OpenBao. Die Passphrase für die Testumgebung ist ein vernünftiger Einstieg, für die Produktion lohnt sich ein verwalteter Schlüssel. Spannend wird es, wenn bereits ein unverschlüsselter State existiert. Dann brauchen Sie eine Übergangsphase, in der OpenTofu beides kann.

10:37 Zuerst sichern Sie den State und legen den Schlüssel getrennt davon ab, sonst liegt beides am selben Ort. Dann tragen Sie eine Methode für unverschlüsselte Daten als Rückfallebene ein. Der nächste Apply liest den alten Stand im Klartext und schreibt ihn verschlüsselt zurück. Danach entfernen Sie die Rückfallebene und erzwingen die Verschlüsselung, damit kein Klartext mehr durchrutscht. Das Ganze wiederholen Sie für die Pläne.

11:01 Und das Beste: Nach genau diesem Muster läuft später auch jede Schlüsselrotation. So wertvoll die Verschlüsselung ist, sie hat Grenzen, und die sollten Sie kennen, bevor Sie sich darauf verlassen. Erstens: Verlieren Sie den Schlüssel, ist der State nicht geschützt, sondern verloren. Die Schlüsselablage wird damit selbst zu kritischer Infrastruktur.

11:22 Zweitens schützt sie nicht davor, dass jemand einen älteren, gültigen State oder Plan wieder einspielt. Drittens sieht jeder, der tofu ausführt, die Geheimnisse weiterhin, denn das Werkzeug muss sie ja entschlüsseln. Die Berechtigungen aus dem ersten Kapitel bleiben also nötig. Und ein praktischer Hinweis: Benennen Sie Key Provider und Methoden nicht um, denn ihre Namen stehen in den Metadaten des State.

Übung

11:45 Genug Theorie. Jetzt verfolgen Sie ein einzelnes Passwort durch das ganze Repository saatplan-infra, finden jede Stelle, an der es auftaucht, und räumen es Schritt für Schritt auf. Die Ausgangslage ist bewusst die schlechteste, die man sich vorstellen kann: eine ungeschützte Variable, ein Output, der das Passwort ausgibt, und das Passwort im Klartext in den Umgebungsvariablen von saatplan-db.

12:08 Ihr Auftrag ist eine kleine Detektivarbeit mit anschließendem Umbau. Es geht dabei weniger um den einen Container als um eine Fähigkeit, die Sie in jedes Projekt mitnehmen: alle Speicherorte eines Geheimnisses aufzuspüren und für jeden einen passenden Schutz zu begründen. Fertig sind Sie, wenn ein Abzug des State das Passwort nicht mehr enthält, kein Output es mehr preisgibt und Sie für jede verbliebene Fundstelle sagen können, was sie schützt.

12:33 Der Weg beginnt mit dem Suchen, nicht mit dem Ändern. Sehen Sie in den State, in einen gespeicherten Plan und ins Pipeline-Log, und notieren Sie jede Fundstelle. Dann entfernen Sie Output und Variable, denn verwaltet wird der Wert künftig im Secret Store. Der Container liest sein Passwort aus einer schreibgeschützten Datei, der Registry-Zugang wandert als flüchtige Variable in den Provider, und für die Testumgebung kommt mit OpenTofu die Verschlüsselung dazu.

12:58 Denken Sie an die Fußzeile: Das Passwort in der bestehenden Datenbank ändert sich dadurch nicht, das ist ein eigener Schritt. Im nächsten Modul geht es dann um die Frage, wie Test und Produktion sauber voneinander getrennt werden.