Container, Registry und Deployment absichern

Container, Registry und Deployment absichern

0:00 Wir sind am Ende der Kette angekommen. Das Artefakt ist gebaut, die Stückliste liegt daneben, die Signatur auch. Bleibt die letzte Vertrauensgrenze — und die liegt nicht im Build, sondern dort, wo das Image tatsächlich gestartet wird. Genau an dieser Stelle entscheidet sich, ob die ganze Arbeit der letzten zwei Tage etwas bewirkt.

0:20 Denn eine Signatur, die beim Start niemand prüft, ist ein Dokument in einer Schublade. Wir bauen heute die Stelle, an der jemand hinsieht.

Container, Registry und Deployment absichern

0:28 Drei Schritte. Zuerst das Image selbst — wie es kleiner und damit angreifbarer wird. Dann die Registry, also der Ort, an dem Artefakt, Signatur und Attestierungen zusammenliegen und wo die Verwaltungsregeln über die Beweiskraft entscheiden. Und schließlich das Deployment: die Regel, die ein Artefakt zulässt oder zurückweist.

0:47 Der letzte Teil ist derjenige, den man am häufigsten weglässt — und ohne den die beiden anderen viel von ihrem Wert verlieren.

Das Image härten

0:56 Beginnen wir beim Image. Hier gilt ein einfacher Zusammenhang, der überraschend viel erklärt: Jedes Paket im Image ist eine Zeile mehr in der Schwachstellenliste, die Sie in Modul elf bearbeiten müssen. Ein kleineres Image ist also nicht nur schneller — es erzeugt dauerhaft weniger Arbeit. Ein gehärtetes Image enthält nur, was zur Laufzeit gebraucht wird.

1:17 Der mehrstufige Build ist das Mittel dafür: Er trennt die Bauumgebung mit Übersetzer, Werkzeugen und Quellcode von der Laufzeitumgebung, in der am Ende nur das Artefakt und seine Laufzeit liegen. Ein Bild dazu: Sie würden nach einem Umbau auch nicht die Gerüste stehen lassen. Im Container passiert genau das erstaunlich oft — im ausgelieferten Image steckt noch der komplette Werkzeugkasten, mit dem gebaut wurde.

1:40 Das Muster in einer Datei. Oben die Baustufe mit dem vollständigen Werkzeugkasten. Unten die Laufzeitstufe, die mit einem schlanken Basis-Image beginnt, einen eigenen Benutzer anlegt, auf diesen wechselt — und dann ausdrücklich genau eine Datei aus der ersten Stufe kopiert. Die Fußzeile beschreibt das Prinzip: Die zweite Stufe erbt nichts aus der ersten außer dem, was ausdrücklich kopiert wird.

2:03 Der Übersetzer, die Quellen, die Maven-Ablage mit allen heruntergeladenen Abhängigkeiten — all das bleibt zurück und taucht in keinem Scan des Endprodukts mehr auf. Drei Entscheidungen, und alle drei trifft man einmal beim Anlegen des Dockerfiles. Das Basis-Image bestimmt, wie viele Betriebssystempakete mitkommen — und damit, wie viele Befunde Sie monatlich bearbeiten.

2:25 Die Ausführung ohne Root-Rechte begrenzt, was ein Einbruch im Container erreicht. Der Verzicht auf Werkzeuge nimmt einem Angreifer das Handwerkszeug: Wer keine Shell und kein Paketwerkzeug im Image findet, hat es deutlich schwerer, sich weiterzubewegen. Und der vierte Punkt fasst zusammen, warum sich das dauerhaft auszahlt: Was nicht im Image ist, muss auch nicht gepatcht werden.

2:47 Drei Ebenen, drei verschiedene Wege zur Behebung — und das ist der praktische Nutzen dieser Tabelle. Befunde im Basis-Image behebt man nicht im eigenen Code, sondern durch ein neueres oder kleineres Basis-Image. Befunde auf Anwendungsebene durch Versionsanhebung oder Ablösung. Und Befunde in der Konfiguration durch eine Änderung im Dockerfile. Wer diese Zuordnung nicht macht, schickt alle Befunde an dasselbe Team und wundert sich über den Rückstand.

3:14 Die Fußzeile nennt den wichtigsten Hebel: Ein Befund im Basis-Image wandert mit jedem Neubau mit, bis das Basis-Image gewechselt wird. Der erste Punkt ist der häufigste und der teuerste: Das Laufzeit-Image enthält noch Übersetzer und Paketmanager aus der Bauphase. Der zweite ist eine Altlast mit einer Begründung, die sich meist auflösen lässt — der Dienst läuft als Root, weil ein Port unterhalb von tausendvierundzwanzig gebraucht wurde; dafür gibt es heute bessere Lösungen.

3:42 Der dritte ist die bewegliche Grundlage: Das Basis-Image hängt an einem Tag und ändert sich unbemerkt. Und der vierte ist der Scan an der falschen Stelle, den wir aus Modul sechs kennen.

Registry und Artefaktverwaltung

3:53 Im zweiten Kapitel geht es um den Ort, an dem alles zusammenkommt. Und um eine Unterscheidung, die für den Rest dieses Moduls trägt: Ein Tag ist ein Zeiger. Ein Digest ist eine Aussage. Wer diesen Unterschied im Deployment ernst nimmt, hat die halbe Arbeit schon getan. Ein Tag verweist auf ein Image und kann jederzeit auf ein anderes verweisen — das ist keine Schwäche, sondern seine Funktion.

4:17 Ein Digest dagegen bezeichnet genau einen Inhalt; er ist aus dem Inhalt berechnet und kann deshalb gar nichts anderes bezeichnen. Deshalb gilt für alles, was wir gestern und heute gebaut haben: Signiert, verifiziert und ausgerollt wird über den Digest. Der Tag bleibt eine Bequemlichkeit für Menschen — praktisch in der Kommandozeile, ungeeignet als Grundlage einer Sicherheitsaussage.

4:40 Vier Schichten, und die mittleren beiden überraschen viele: Signatur und Attestierungen liegen als eigenständige Artefakte neben dem Image, nicht darin. Das hat einen praktischen Vorteil — man kann nachträglich signieren, ohne das Image zu verändern — und einen Nachteil, der uns gleich begegnet: Beim Umkopieren können sie zurückbleiben.

4:59 Die vierte Schicht ist die, an die niemand denkt: die Verwaltungsregeln. Aufbewahrung, Unveränderlichkeit, Schreibrechte. Sie sind kein Betriebsdetail, sondern entscheiden darüber, ob Ihre Nachweise in einem Jahr noch existieren. Vier Regeln mit unmittelbarer Wirkung. Unveränderliche Tags verhindern, dass ein veröffentlichter Stand überschrieben wird — das schließt die Bedrohung „Artefakt ersetzt" aus Modul eins an ihrer Wurzel.

5:24 Schreibrechte gehören der Pipeline, nicht den Personen; das ist dieselbe Logik wie in Modul sieben. Aufbewahrungsregeln dürfen kein Image löschen, das noch produktiv läuft — und das kommt häufiger vor, als man denkt, wenn eine Altumgebung vergessen wird. Und der vierte Punkt ist der praktische Stolperstein: Beim Umkopieren zwischen Registries müssen Signatur und Attestierungen mitwandern.

5:48 Drei Festlegungen: wer schreiben darf, welche Tags unveränderlich sind, und wie lange Images samt Signatur und Attestierungen aufbewahrt werden. Der Hinweis verweist zurück auf Modul acht — dort haben Sie eine Aufbewahrungsfrist für Build-Nachweise festgelegt. Beide müssen zusammenpassen, sonst haben Sie in achtzehn Monaten die Provenance ohne das Image oder umgekehrt.

6:09 Nehmen Sie sich für diesen Abgleich fünf Minuten; er verhindert einen Fehler, der erst auffällt, wenn es zu spät ist. Der erste Punkt ist der Klassiker unter den Registry-Fehlern: Ein Release-Tag wird überschrieben, weil noch schnell etwas korrigiert wurde. Damit bezeichnet dieselbe Versionsangabe zwei verschiedene Inhalte, und jede Aussage über „Version eins Punkt vier" wird mehrdeutig.

6:32 Der zweite ist die Aufräumregel, die eine Altumgebung übersieht. Der dritte ist die unbemerkte Rechteausweitung — Personen mit Schreibrechten auf die Registry, meist aus einer einmaligen Notlage entstanden. Und der vierte ist der praktische Ärger beim Umkopieren, der die Verifikation im Deployment scheitern lässt.

Deployment kontrollieren

6:51 Jetzt zum entscheidenden Kapitel. Alles, was wir gebaut haben, läuft hier zusammen — und wird entweder wirksam oder bleibt Dokumentation. Der Unterschied liegt in einem einzigen Punkt: Wo greift die Regel? In der Pipeline oder dort, wo das Image tatsächlich gestartet wird? Artefakt-Attestierungen sind kryptografisch signierte Aussagen, die Herkunft und Integrität belegen — sie verbinden ein Artefakt mit Workflow, Repository, Organisation, Commit und auslösendem Ereignis.

7:03 Bemerkenswert ist die Einordnung, die GitHub selbst vornimmt: Für sich genommen erreichen sie SLSA Build Level zwei. Für Level drei braucht es zusätzlich die Isolation über wiederverwendbare Abläufe. Das ist eine erfreulich ehrliche Angabe — und sie hilft Ihnen bei der Bewertung aus Modul dreizehn, weil Sie damit einen belegten Ausgangspunkt haben statt einer Schätzung.

7:25 Diese Klarstellung steht so in der Dokumentation, und sie ist wichtig. Eine Attestierung liefert Metadaten über den Bau — nicht eine Aussage über die Qualität des Codes. Ihr Wert entsteht erst durch eine Regel, die aus diesen Metadaten eine Entscheidung macht. Zwei technische Details noch, die man kennen sollte: Für öffentliche Repositories wird die öffentliche Sigstore-Instanz mit Transparenzprotokoll genutzt.

7:49 Für private Repositories nutzt GitHub eine eigene Instanz ohne Transparenzprotokoll. Das ist nachvollziehbar — man möchte interne Projektnamen nicht öffentlich protokollieren —, aber Sie sollten es wissen, wenn Sie den Nachweis anführen. Fünf Schritte, und der vierte ist der, um den es geht: Die Prüfung im Cluster beim Zulassen erzwingen, nicht nur in der Pipeline prüfen.

8:11 Davor die inhaltlichen Festlegungen — welches Repository, welcher Ablauf, welche Identität, und die Bindung an den Digest. Danach die Forderung, dass Provenance und Stückliste überhaupt vorliegen. Und der fünfte Schritt ist der, den man im Eifer vergisst: Ablehnungsfall und Notfallweg vorher festlegen. Die Fußzeile sagt, was sonst passiert — ohne festgelegten Notfallweg wird die Regel beim ersten Störfall dauerhaft abgeschaltet.

8:37 Zwei Zeilen, und die rechte Spalte macht den Unterschied deutlich. Eine Prüfung in der Pipeline wirkt gegen Fehler im eigenen Ablauf — sie fängt das versehentlich falsch gebaute Image ab. Sie wirkt nicht gegen einen Start an der Pipeline vorbei, und genau das passiert im Notfall. Die Prüfung beim Zulassen im Cluster wirkt gegen jedes nicht zugelassene Image, ganz gleich wie es dorthin kam.

8:59 Sie wirkt nicht gegen Manipulation nach dem Start — dafür braucht es andere Mittel. Die Fußzeile: Erst der zweite Prüfpunkt macht aus der Signatur eine Bedingung statt eines Hinweises. Der erste Punkt ist der, der die ganze Kette aushebelt: Die Prüfung läuft nur in der Pipeline, und ein Notfall-Deployment geht daran vorbei.

9:18 Der zweite ist die halbe Regel — sie verlangt eine Signatur, aber keine bestimmte Identität; wir kennen das aus Modul zwölf als grünen Haken ohne Inhalt. Der dritte betrifft die Gegenrichtung: Widerruf und Rollback sind nicht geübt, und im Ernstfall fehlt der letzte gute Stand, weil ihn die Aufbewahrungsregel gelöscht hat.

9:36 Und der vierte ist die Ausnahme ohne Frist, die zur Regel wird.

Übung

9:40 In der Übung gehen Sie den ganzen Weg: vom mehrstufigen Build über den Digest im Deployment bis zur Regel, die ein unsigniertes Image zurückweist. Und wie in Modul zwölf ist der letzte Schritt der wichtigste — die Ablehnung muss tatsächlich stattfinden und protokolliert sein. Drei überprüfbare Ergebnisse: Das Image läuft ohne Root aus einem mehrstufigen Build. Das Deployment verweist auf einen Digest.

10:03 Und ein unsigniertes Image wird beim Zulassen abgelehnt. Der Hinweis nennt einen Nebeneffekt, der später wichtig wird: Protokollieren Sie den Ablehnungsfall. Im letzten Modul stellen wir ein technisches Nachweispaket zusammen, und ein dokumentierter Ablehnungsfall ist darin einer der überzeugendsten Belege — er zeigt nicht, dass eine Kontrolle existiert, sondern dass sie wirkt.

10:26 Den Build auf zwei Stufen umstellen und das Laufzeit-Image verkleinern. Einen eigenen Benutzer anlegen und ohne Root starten. Das Deployment auf den Digest umstellen — das ist der Schritt, der im Alltag am meisten Umgewöhnung kostet, weil Tags bequemer sind. Die Regel einrichten, die Signatur und Provenance verlangt. Und ein unsigniertes Image ausrollen, um die Ablehnung zu belegen.

10:49 Die Fußzeile ist derselbe Gedanke wie in Modul zwölf: Wer Schritt fünf auslässt, weiß am Ende nicht, ob die Regel überhaupt greift. Der erste Punkt ist ein Widerspruch, der öfter vorkommt, als man glaubt: Das Deployment bleibt auf einem Tag, obwohl die Regel den Digest prüft — dann prüft die Regel etwas anderes als das, was startet.

11:09 Der zweite ist der Umgebungsfehler: Die Regel steht im Testnamensraum und wurde in der Produktion vergessen. Der dritte ist der ungeübte Rollback-Weg, der am fehlenden alten Image scheitert. Und der vierte kostet Sie einen Nachweis, den Sie im letzten Modul gebrauchen könnten: Die Ablehnung wird nicht protokolliert und taucht nirgends auf.