Container-Sicherheit und Supply Chain

Container-Sicherheit und Supply Chain

0:00 Bisher haben wir gefragt: Funktioniert es? In diesem Modul fragen wir etwas anderes: Können wir dem trauen, was wir ausliefern? Das ist eine Frage, die in den letzten Jahren vom Nebenthema zur Pflicht geworden ist — durch spektakuläre Angriffe auf Lieferketten, durch Regulierung, durch Kunden, die inzwischen Nachweise verlangen.

0:18 Wir gehen den Weg in sieben Schritten: Wir nehmen dem Container Rechte weg, wir sehen nach, was drinsteckt, wir schreiben eine Stückliste, wir signieren, wir belegen die Herkunft — und am Ende machen wir all das zur Eintrittsbedingung im Cluster. Erst dann hat es Wirkung.

Das Image härten

0:34 Beginnen wir mit dem günstigsten Teil der ganzen Sicherheitsarbeit. Härtung kostet keine Lizenz, kein Werkzeug und keine Infrastruktur — nur Sorgfalt beim Bauplan. Und die Regel dahinter ist eine, die man sich leicht merkt: Rechte, die niemand braucht, gehören weggenommen. Das Prinzip heißt in der Fachwelt geringstes Privileg, und im Alltag kennen Sie es vom Schlüsselbund.

0:57 Der Reinigungsdienst braucht den Schlüssel für die Büros, nicht den für den Serverraum. Genauso nehmen wir dem Container alles, was er zur Erfüllung seiner Aufgabe nicht braucht: die Kennung des Verwalters, das Schreibrecht auf sein eigenes Dateisystem, die Möglichkeit, Rechte hinzuzugewinnen, und die Sonderrechte des Kerns.

1:15 Was übrig bleibt, ist ein Prozess, der lesen, rechnen und antworten darf — und sonst nichts. Das klingt nach Einschränkung. Für einen Webdienst ist es genau die Beschreibung seiner Aufgabe. Hier kommen zwei Dinge aus Modul 1 zusammen: der Mehrstufen-Bau und ein minimales Basis-Image. Achten Sie aber auf die vorletzte Zeile, denn dort steht eine Zahl und kein Name — und das ist ausdrücklich Absicht.

1:38 Ein minimales Basis-Image bringt oft gar keine Benutzerdatenbank mit. Es gibt dort niemanden, den man beim Namen nennen könnte, und eine Kennung per Name scheitert dann beim Start. Eine numerische Kennung wirkt immer, weil der Kern ohnehin nur mit Zahlen arbeitet. Nehmen Sie sich einen hohen Wert und verwenden Sie ihn im ganzen Projekt einheitlich — das macht spätere Rechteprobleme lesbar.

2:02 Diese sechs Einstellungen sind nicht willkürlich gewählt, und deshalb lohnt es, sie hier genau anzusehen: Es sind genau die, die das strenge Profil aus Kapitel 6 prüft. Wer sie jetzt setzt, kommt später ohne Diskussion durch die Eingangsprüfung. Inhaltlich ordnen sie sich in drei Gruppen: Wer bin ich — die ersten beiden.

2:20 Was darf ich dazugewinnen — die nächsten beiden. Und was darf ich verändern oder beim Kern anfragen — die letzten beiden. Die vierte Zeile ist übrigens die wirkungsvollste und die am seltensten gesetzte: Alle Sonderrechte des Kerns fallen zu lassen, kostet einen normalen Webdienst nichts. Das ist ein Vorgriff auf Modul 5, aber er gehört hierhin, weil er ein verbreitetes Missverständnis auflöst. Der Bauplan allein genügt nämlich nicht.

2:46 Sie können ein perfekt gehärtetes Image nehmen und es im Cluster mit Verwalterrechten, beschreibbarem Dateisystem und allen Sonderrechten betreiben — das Image hindert Sie nicht daran. Das Image sagt, was drin ist. Das Manifest sagt, mit welchen Rechten es läuft. Beides sind getrennte Entscheidungen, und erst zusammen tragen sie.

3:06 Deshalb der Rat: Schreiben Sie diesen Block einmal sauber und nehmen Sie ihn als Vorlage in jedes Deployment mit. Lassen Sie mich das an einem Ablauf erklären, denn diese vier Punkte sind eigentlich vier Hürden auf einem Weg. Jemand findet eine Lücke in Ihrem Dienst und kann Code ausführen. Erste Hürde: Er ist niemand Besonderes, die Lücke bleibt auf den Dienst begrenzt und der Rechner ist nicht in Gefahr.

3:30 Zweite Hürde: Er kann nichts ablegen, weil das Dateisystem unveränderlich ist. Dritte Hürde: Es gibt keine Shell und keine Paketverwaltung, sein gewohntes Handwerkszeug fehlt. Jede Hürde einzeln ist überwindbar. Alle zusammen machen aus einem lohnenden Ziel ein mühsames. Und der vierte Punkt spart Ihnen jede Woche Arbeit: weniger Pakete, weniger zu bewertende Meldungen.

3:53 Diese Übung ist die praktische Probe auf das Kapitel: Bauen und beschreiben Sie einen Dienst so, dass er ohne Verwalterrechte und ohne Schreibrecht auf sein Dateisystem arbeitet. Geschafft ist es, wenn er unverändert antwortet. Wer schneller fertig ist, geht den interessanteren Weg: die Pfade suchen, die der Dienst doch beschreiben muss, und sie als Ablage nachreichen. Denn die gibt es fast immer.

4:15 Zwischenspeicher und Protokollpfade sind die üblichen zwei Stellen, an denen es zuerst klemmt — und die Lösung ist nicht, das Schreibrecht wieder freizugeben, sondern genau einen schreibbaren Ort bereitzustellen. Der erste Punkt ist die Erfahrung aus der Übung, und er ist die häufigste Ursache für einen abgebrochenen Härtungsversuch: unveränderliches Dateisystem ohne Pfad für Zwischendateien, und der Dienst startet nicht mehr.

4:39 Der zweite ist der Namensfehler von der Code-Folie — im minimalen Basis-Image gibt es die Benutzerdatenbank nicht. Der dritte ist der Widerspruch, den wir gerade besprochen haben: gehärteter Bauplan, laxes Manifest. Das passiert, wenn verschiedene Personen die beiden Dateien pflegen. Und der vierte kommt aus Modul 1 zurück und trifft jeden einmal: minimales Basis-Image ohne Zeitzone und Wurzelzertifikate, und keine verschlüsselte Verbindung funktioniert mehr.

Schwachstellen finden

5:05 Jetzt die einfachste Frage dieses Moduls, und die unbequemste: Was steckt eigentlich in Ihrem Image? Man weiß es erst nach dem Nachsehen — und Nachsehen ist der erste Schritt in diesem Modul, der wirklich automatisiert gehört, weil er sich jede Woche wiederholt. Ein Scanner arbeitet unspektakulärer, als man denkt: Er liest die Paketlisten Ihres Images aus, vergleicht die gefundenen Fassungen mit öffentlichen Meldungsdatenbanken und berichtet, was betroffen ist.

5:32 Er versteht Ihren Code nicht und beurteilt ihn nicht. Diese Abgrenzung ist wichtig, damit Sie sich nicht in falscher Sicherheit wiegen: Der Scanner findet nichts über selbst geschriebenes, sondern über alles Mitgelieferte — Basis-Image, Systempakete, Abhängigkeiten der Anwendung. Das ist übrigens keine Kritik. In einem typischen Image kommen mehr als neunzig Prozent des Codes von woanders. Genau dort liegt statistisch auch das Risiko.

5:58 Fünf Zeilen, und die vierte ist die eigentliche Botschaft. Ohne den Abbruchcode meldet der Scanner brav, was er gefunden hat, und die Pipeline läuft grün weiter — und nach drei Wochen liest niemand mehr hin. Ein Prüfschritt, der nichts verhindert, ist Dekoration. Die zweite und dritte Zeile sind es, die den Abbruch erträglich machen: Wir beschränken auf die hohen Stufen und blenden Meldungen ohne verfügbare Behebung aus.

6:22 Dieses Ausblenden ist keine Nachlässigkeit, sondern Handlungsfähigkeit — was Sie nicht beheben können, hilft in einer Abbruchbedingung niemandem. Und: geprüft wird über den Digest, nie über den Tag. Das ist die angenehme Überraschung an diesem Werkzeug: Es kann mehr als Schwachstellen. Die zweite Zeile ist die, die ich Ihnen wirklich ans Herz lege — versehentlich mitgelieferte Zugangsdaten und Schlüssel.

6:47 Wir haben in Modul 1 gesehen, dass ein Passwort in einer Schicht nicht verschwindet, wenn man es löscht. Genau das findet dieser Prüfer, und zwar bevor das Image die Registry erreicht. Die dritte Zeile prüft riskante Einstellungen in Bauplänen und Manifesten und ist eine gute Ergänzung. Beachten Sie den Hinweis darunter: Nur die ersten zwei laufen voreingestellt.

7:08 Die anderen müssen Sie ausdrücklich wählen. Der rote Faden hier ist Reihenfolge, und sie ist der Grund, warum Scan-Einführungen scheitern. Wer mit Abbruch anfängt, hat am ersten Tag eine rote Pipeline und am zweiten Tag ein Team, das den Scan abschaltet. Also umgekehrt: erst schauen, was überhaupt da ist. Dann die Schwelle setzen, dann das Unbehebbare ausblenden. Schritt vier ist der, der über das Jahr entscheidet: Ausnahmen bekommen ein Ablaufdatum.

7:36 Ohne das wird jede Ausnahme zum Dauerzustand, den niemand mehr prüft — und Ihre Ausnahmedatei wird zum Archiv der Probleme, die Sie einmal hatten. Erst am Ende, mit Schritt fünf, kommt der Abbruch. Die ersten zwei Punkte sind die beiden Enden derselben Achse, und beide enden gleich: Der Scan verliert seine Wirkung. Ohne Abbruch wird die Meldung zur Gewohnheit.

7:58 Bei Abbruch auf jeder Stufe ist die Pipeline dauerhaft rot, und was dauerhaft rot ist, wird ignoriert oder umgangen. Suchen Sie die Mitte. Der dritte Punkt ist die Ausnahme ohne Ablaufdatum aus dem Vorgehen — ich nenne ihn zweimal, weil er so verbreitet ist. Und der vierte betrifft die Abdeckung: Nur das fertige Image zu prüfen kann die Abhängigkeiten Ihrer Anwendung übersehen, gerade wenn sie in einer früheren Bau-Etappe entstanden sind.

Die Stückliste zum Image

8:23 Jetzt zu einem Thema, das erst durch die Regulierung Aufmerksamkeit bekommen hat und das im Ernstfall über Stunden oder Tage entscheidet. Es geht um den Unterschied zwischen „wir glauben, wir sind nicht betroffen" und „wir wissen es". Ein Verzeichnis dessen, was mitgeliefert wurde. Eine Stückliste, im Fachjargon SBOM, ist genau das, was der Name sagt — nur maschinenlesbar. Jeder Bestandteil mit Name, Fassung und Herkunft.

8:49 Denken Sie an das Zutatenverzeichnis auf einer Lebensmittelpackung: nicht spannend, bis jemand eine Allergie hat. Wichtig ist der zweite Satz: Sie entsteht beim Bauen, nicht beim Aufräumen — denn beim Bauen weiß die Maschine noch genau, was hineingegangen ist. Zwei Formate haben sich durchgesetzt. SPDX kommt aus der Lizenzarbeit, CycloneDX aus der Sicherheitsarbeit.

9:12 Beide lassen sich aus demselben Image erzeugen, und meist erzeugt man einfach beide. Zwei Werkzeuge, dasselbe Ergebnis — und das zeigt schön, dass Sie hier nicht in einer Werkzeugentscheidung feststecken. Das erste, syft, ist auf Stücklisten spezialisiert und gibt beide Formate in einem Lauf aus. Das zweite ist der Scanner von vorhin, der das nebenbei mit erledigt — praktisch, wenn Sie ihn schon in der Pipeline haben.

9:37 Der eigentliche Hinweis steht unten und ist der wichtigste Satz dieses Kapitels: Erzeugt wird über den Digest, nicht über den Tag. Eine Stückliste, die sich auf einen beweglichen Zeiger bezieht, passt in sechs Monaten zu nichts mehr — und dann ist sie schlimmer als keine. Zwei Formate und eine sehr pragmatische dritte Zeile.

9:56 Die Herkunft erklärt die Unterschiede: Das eine kommt aus der Lizenzarbeit, ist breit anerkannt und inzwischen sogar ISO-Norm — das zählt, wenn Verträge und Aufsicht im Spiel sind. Das andere kommt aus der Sicherheitsarbeit und liegt näher an Schwachstellendaten, weshalb Sicherheitswerkzeuge es meist bevorzugen. Und die dritte Zeile ist die Praxis: Man erzeugt beide, weil verschiedene Abnehmer verschiedene Formate verlangen und die Erzeugung fast nichts kostet.

10:23 Der Hinweis darunter ist realistisch: Die Wahl ist selten Ihre. Kunden, Aufsicht und Werkzeuge geben sie meistens vor. Machen wir es konkret, denn abstrakt überzeugt dieses Thema niemanden. Es wird eine schwere Lücke in einer weit verbreiteten Bibliothek gemeldet. Ohne Stücklisten beginnt jetzt eine Suche über alle Ihre Dienste, und sie dauert Tage.

10:44 Mit Stücklisten ist es eine Abfrage und in Minuten klar, welche Auslieferungen betroffen sind. Genau das ist der erste Punkt, und er allein rechtfertigt den Aufwand. Der zweite ist die Präzision durch den Digest — die Liste gilt für genau eine Fassung. Der dritte spart Ihnen Lizenzarbeit. Und der vierte ist der pragmatische: Abnehmer und Aufsicht verlangen sie zunehmend als Teil der Lieferung.

11:08 Der erste Punkt ist der aus der Code-Folie, und ich wiederhole ihn, weil er die Liste stillschweigend wertlos macht: nachträglich vom Tag erzeugt, bezieht sie sich auf eine andere Fassung als die ausgelieferte. Der zweite betrifft die Vollständigkeit — nur Systempakete zu erfassen und die Abhängigkeiten der Anwendung auszulassen, deckt die kleinere Hälfte des Risikos.

11:29 Der dritte ist eine Organisationsfrage mit Folgen: Eine Liste, die im Bauverzeichnis liegen bleibt, ist in sechs Monaten weg. Sie gehört an das Image gebunden, und wie das geht, sehen wir in Kapitel 5. Und der vierte ist eine Erwartungskorrektur: Die Liste zählt auf, sie bewertet nicht.

Images signieren mit Cosign

11:46 Jetzt kommen wir zum Kern dieses Moduls. Bisher ging es darum, was in einem Image steckt. Jetzt geht es um eine andere Frage, und sie ist bei Lieferkettenangriffen die entscheidende: Wer hat dieses Image gebaut, und lässt sich das nachweisen? Ab hier wird die Lieferkette prüfbar. Eine Signatur bindet eine Aussage über ein Image an eine nachweisbare Identität — das ist der Kern.

12:09 Interessant ist das schlüssellose Verfahren, denn es löst das Problem, an dem klassische Signaturen in der Praxis scheitern: Es gibt keinen privaten Schlüssel zu verwahren. Der Bauvorgang weist sich über einen kurzlebigen Identitätsnachweis aus, bekommt dafür ein befristetes Zertifikat und legt die Signatur in ein öffentliches, unveränderliches Protokoll.

12:29 Das Bild dazu ist der Notar: Sie brauchen keinen eigenen Siegelstempel im Schreibtisch — Sie weisen sich aus, und der Vorgang wird protokolliert. Geprüft wird deshalb gegen Identität und Ausgeber, nicht gegen einen Schlüssel. Der Befehl selbst ist kurz — der Kommentar darüber ist der Inhalt dieser Folie. Der Digest kommt aus dem Bauschritt, nicht der Tag.

12:50 Und der Hinweis darunter erklärt, warum das hier noch schwerer wiegt als bei der Stückliste: Ein Tag lässt sich umhängen. Wenn Sie über den Tag signieren und jemand ihn später auf ein anderes Image zeigen lässt, gilt Ihre Signatur formal weiter — für ein Image, das niemand geprüft hat. Das ist keine theoretische Lücke, das ist genau der Angriffsweg, gegen den Sie sich hier absichern.

13:13 Signieren Sie also, was Sie gebaut haben, und nicht, was der Name gerade bezeichnet. Diese Folie räumt mit dem verbreitetsten Fehler in diesem Themenfeld auf. Der Prüfbefehl allein sagt nämlich fast nichts — er sagt nur, dass irgendwer irgendwann signiert hat. Und irgendwer kann jeder sein, denn das schlüssellose Verfahren steht allen offen.

13:33 Erst die beiden Angaben hier machen daraus eine Aussage: Die Signatur muss von einer Identität aus unserem Projekt kommen, und sie muss von diesem bestimmten Identitätsdienst bestätigt worden sein. Denken Sie an eine Unterschrift auf einem Vertrag: Dass sie da ist, beruhigt nicht. Dass sie von der vertretungsberechtigten Person kommt, beruhigt.

13:53 Vier Bestandteile, und der Hinweis darunter ist die eigentliche Botschaft: Fehlt einer, bleibt die Prüfung eine Formalie. Der Digest benennt, was geprüft wird — ohne ihn prüfen Sie einen Namen. Die Identität benennt, wer signiert hat. Der Ausgeber benennt, wer das bestätigt hat, und ohne ihn könnte jeder Identitätsdienst behaupten, was er will.

14:14 Und der Protokolleintrag belegt, dass die Signatur zum Zeitpunkt existierte — er verhindert, dass jemand rückwirkend etwas behauptet. Diese vier zusammen sind keine Bürokratie. Sie sind der Unterschied zwischen einem Häkchen in der Pipeline und einer Aussage, die vor einem Prüfer trägt. Ihre Aufgabe: ein Artefakt ohne verwahrten Schlüssel signieren und die Prüfung so formulieren, dass sie eine echte Aussage trägt.

14:39 Der Erfolg hat zwei Hälften, und die zweite ist die wichtigere: Die Prüfung des eigenen Images gelingt mit Identität und Ausgeber — und dieselbe Prüfung schlägt bei einem fremden Image fehl. Genau dieser Gegentest ist der Teil, der überzeugt, denn eine Prüfung, die nie etwas ablehnt, hat nichts belegt. Wer schneller fertig ist, sucht den eigenen Eintrag im öffentlichen Protokoll. Das ist ein lohnender Moment: Ihre Signatur liegt dort, weltweit lesbar und nicht mehr entfernbar.

15:07 Die ersten drei Punkte kennen Sie jetzt, und ich fasse sie in einem Satz zusammen: über den Digest signieren, mit Identität und Ausgeber prüfen. Der dritte ist ein praktischer, der viele Teams beim ersten Registry-Umzug erwischt: Signaturen liegen als eigene Artefakte in der Registry und wandern beim Umkopieren nicht automatisch mit.

15:26 Danach ist alles unsigniert, und niemand versteht warum. Der vierte Punkt ist eine Erwartungskorrektur, die mir wichtig ist: Eine Signatur sagt nichts über die Sicherheit des Inhalts. Sie sagt, wer es gebaut hat. Ein signiertes Image mit dreißig Schwachstellen bleibt ein Image mit dreißig Schwachstellen.

Provenance und SLSA

15:44 Weiter zu einer Frage, die noch eine Ebene tiefer geht. Nicht, was drin ist — nicht einmal, wer signiert hat. Sondern: wie ist es entstanden? Hier ordnet sich der eigene Bauprozess in ein Stufenmodell ein, und das Ergebnis ist beim ersten Mal meist ernüchternd. Provenance ist ein Begriff aus dem Kunsthandel — die belegte Herkunftsgeschichte eines Objekts, von der Werkstatt bis zur Wand.

16:08 Übertragen heißt das: welcher Bauvorgang hat dieses Artefakt aus welchen Quellen auf welcher Plattform erzeugt? SLSA beschreibt dafür Stufen. Die aktuelle Fassung kennt einen Build-Track mit den Stufen Null bis Drei. Und das Ordnungsprinzip ist elegant, deshalb merken Sie sich diesen Satz: Jede Stufe verschiebt die Frage, wem man vertrauen muss, weiter von Personen zur Plattform.

16:31 Denn Personen können sich irren, unter Druck geraten oder ihre Zugangsdaten verlieren. Eine Plattform kann man prüfen. Vier Stufen, und der Sprung, auf den es ankommt, liegt zwischen der ersten und der zweiten. Auf Stufe eins existiert eine Herkunftsbeschreibung — aber Sie haben sie geschrieben. Auf Stufe zwei erzeugt und signiert die Bauplattform sie selbst, und damit ist sie nicht mehr Ihre Behauptung. Das ist der eigentliche Gewinn.

16:56 Stufe drei verlangt gehärtete Bauläufe, die einander nicht beeinflussen können — dort landen Sie nicht durch Sorgfalt, sondern durch die Wahl der Plattform. Und lesen Sie den Hinweis: Eine vierte Stufe gibt es in der aktuellen Fassung nicht mehr. Sie stammt aus der Entwurfsfassung und steht noch in vielen älteren Artikeln.

17:15 Hier schließt sich der Kreis zu Kapitel 3, und dieser Befehl löst genau den Stolperstein von dort. Die Stückliste liegt nicht mehr als Datei irgendwo herum — sie wird zu einer signierten Aussage, die am Digest hängt. Der Unterschied ist erheblich, auch wenn er auf der Folie klein aussieht: Eine Datei im Bauverzeichnis kann jeder schreiben und niemand findet sie in sechs Monaten.

17:37 Eine Aussage am Image ist signiert, auffindbar und einer Identität zugeordnet. Merken Sie sich das Muster: Alles, was Sie über ein Image behaupten, kann als Aussage daran gebunden werden — Stückliste, Prüfbericht, Freigabe. Das klingt zunächst unfreundlich gegenüber Menschen, ist aber eine nüchterne Feststellung über Nachweise.

17:56 Der erste Punkt ist der Kern: Eine Aussage, die der Bauvorgang selbst erzeugt, kann niemand hinterher schreiben — auch nicht unter Druck, auch nicht aus Versehen. Der zweite ist die Begründung für Stufe drei: Getrennte Bauläufe verhindern, dass ein Auftrag den nächsten beeinflusst; ohne diese Trennung könnte ein manipulierter Auftrag den Nachbarn vergiften.

18:16 Der dritte macht Fassungen zuordenbar, indem er Quellstand und Bauplattform nennt. Und der vierte ist der unromantische, der Budgets bewegt: Für regulierte Abnehmer ist die Stufe eine Zahl, über die man verhandeln kann. Der erste Punkt ist der schöne Selbstwiderspruch, und man sieht ihn häufiger, als man denkt: Provenance am eigenen Arbeitsplatz erzeugen.

18:36 Damit ist sie genau das, was sie nicht sein soll — Ihre Behauptung. Der zweite ist eine Selbsteinschätzungsfalle: Eine Stufe zu behaupten, ohne die Härtung der Bauläufe je geprüft zu haben, hält keiner Prüfung stand. Der dritte ist der stille Leerlauf, den ich am häufigsten sehe: Aussagen fleißig anhängen und beim Abnehmer nie prüfen lassen.

18:56 Und der vierte ist eine Begriffsverwechslung mit Folgen: Provenance beschreibt den Weg, die Stückliste den Inhalt. Wer das eine liefert und das andere gemeint hat, liefert am Bedarf vorbei.

Pod Security Standards

19:07 Ab jetzt wechseln wir die Seite. Bisher haben wir Nachweise erzeugt — jetzt sorgen wir dafür, dass sie im Cluster tatsächlich etwas bewirken. Und wir beginnen mit dem eingebauten Weg: drei Profile, drei Betriebsarten, ein Label. Er kostet nichts und wird trotzdem selten genutzt. Kubernetes bringt eine Eingangsprüfung mit, die jeden eingereichten Pod gegen drei abgestufte Profile hält: unbeschränkt, grundlegend abgesichert und streng.

19:35 Das strenge ist genau jenes, dessen sechs Anforderungen wir in Kapitel 1 gesehen haben — hier zahlt sich die Vorarbeit aus. Jedes Profil lässt sich in drei Betriebsarten aktivieren: erzwingend, warnend oder nur protokollierend. Und das Bemerkenswerteste ist die Bedienung: gesteuert wird über Labels am Namensraum. Keine eigene Ressource, kein zusätzliches Werkzeug, keine Installation.

19:58 Vier Zeilen an einer Stelle, die Sie ohnehin schon haben. Deshalb finde ich es erstaunlich, wie oft dieser Weg ungenutzt bleibt. Vier Labels, und beachten Sie, dass hier alle drei Betriebsarten gleichzeitig gesetzt sind — das ist eine sinnvolle Endkonfiguration, aber nicht der Anfang. Der Einführungsweg steht auf der Folie danach.

20:18 Wichtiger ist der Hinweis unten, und der betrifft die zweite Zeile: Die Profilfassung festzuschreiben statt „latest" zu nehmen, verhindert Überraschungen beim Cluster-Update. Denn diese Profile werden weiterentwickelt und mit der Zeit strenger. Wer auf „latest" steht, bekommt neue Anforderungen genau in dem Moment, in dem der Cluster aktualisiert wird — also dann, wenn Sie ohnehin genug zu tun haben.

20:41 Drei Betriebsarten, und ihr Nutzen liegt in der Kombination: Man führt warnend ein und erzwingt später. Die Warnung geht dabei an den Einreichenden — also an die Person oder Pipeline, die das Manifest schickt, und damit an die richtige Stelle. Das Prüfprotokoll ist für den Bestandsüberblick da. Ganz wichtig ist der Hinweis darunter, und er überrascht regelmäßig: Erzwingen greift nur bei Pods.

21:05 Wenn Sie ein Deployment einreichen, wird es angenommen — und erst der Pod, den es erzeugen will, wird abgelehnt. Sie sehen also nichts im Deployment, sondern einen Pod, der nie hochkommt. Über Warnung und Protokoll erfahren Sie es früher. Das ist dieselbe Lektion wie beim Scanner, und sie gilt in diesem Modul immer: Erst sehen, dann erzwingen. Warnend eingeführt zeigt sich der Bestand, ohne dass etwas ausfällt.

21:30 Der zweite Punkt ist eine trügerische Beruhigung: Bestehende Pods bleiben unberührt, erst der nächste Start wird geprüft. Trügerisch, weil es so aussieht, als sei alles in Ordnung — bis nachts ein Knoten neu startet und plötzlich die Hälfte nicht mehr hochkommt. Der dritte Punkt ist die direkte Konsequenz. Und der vierte ist eine Warnung für später: Ausnahmen für Dienstkennungen wirken weiter, als es zunächst aussieht — sie gelten für alles, was diese Kennung einreicht.

21:57 Der erste Punkt ist das Szenario von der letzten Folie, und es ist der klassische Fehlstart: sofort erzwingen und beim nächsten Neustart den halben Namensraum verlieren. Der zweite ist die Deployment-Falle aus der Tabelle — die Ablehnung passiert am Pod und ist deshalb schwer zu finden. Der dritte ist die Fassungsfrage: „latest" beschert Ihnen strengere Regeln zum Zeitpunkt des Cluster-Updates.

22:19 Und der vierte ist der gefährlichste, weil er nach einer kleinen Erleichterung aussieht: Eine Ausnahme für eine Steuerungskennung gibt weit mehr frei als gedacht, denn über diese Kennung laufen sehr viele Pods. Ausnahmen gehören auf einzelne Namensräume, nicht auf Kennungen.

Policy-as-Code mit Kyverno

22:35 Und nun der Schlussstein. Wir haben in diesem Modul Signaturen, Stücklisten und Herkunftsnachweise erzeugt — bislang ohne Wirkung, denn niemand hat sie verlangt. Genau das ändern wir jetzt: Nur was geprüft ist, darf in den Cluster. Hier wird alles Vorige zur Eintrittsbedingung. Die eingebaute Prüfung aus Kapitel 6 kann Profile, aber keine Aussagen über Herkunft — sie weiß nichts von Signaturen.

22:59 Deshalb tritt daneben eine zweite Eingangsprüfung, hier Kyverno. Ihr Kunstgriff ist, dass sie Regeln als gewöhnliche Ressourcen im Cluster liest. Ihre Sicherheitsregeln liegen also als YAML im Repository, gehen durch Review und durch die Pipeline wie jeder andere Code — daher der Name Policy-as-Code. Für unser Thema gibt es eine eigene Regelart: Sie prüft Signaturen und ersetzt den Tag dabei durch den Digest. Beachten Sie diese zweite Wirkung, sie ist mehr als eine Beigabe.

23:29 Die Regel ist gekürzt, aber ihr Aufbau ist gut zu lesen: Auf welche Objekte zielt sie, auf welche Images, und was passiert bei einem Verstoß. Zwei Zeilen sind hervorzuheben. Die erste ist die Erzwingung — und ein Praxishinweis dazu, der Ihnen Sucharbeit erspart: Dieser Schalter sitzt seit Fassung 1.13 in der Regel und nicht mehr oben in der Spezifikation.

23:50 Viele Beispiele im Netz zeigen noch die alte Stelle. Die zweite ist die Digest-Ersetzung: Beim Zulassen wird der Tag durch den Digest ersetzt. Damit läuft im Cluster garantiert genau das Image, das geprüft wurde — die Faustregel aus Modul 1, endlich durchgesetzt. Zwei Zeilen, und es sind dieselben zwei Angaben wie beim Prüfbefehl aus Kapitel 4: Identität und Ausgeber. Das ist kein Zufall, es ist derselbe Gedanke an anderer Stelle.

24:17 Und der Hinweis darunter ist die gleiche Warnung wie dort, nur mit größerer Reichweite: Ohne diese Zeilen prüft die Regel nur, dass überhaupt signiert wurde. Das schlüssellose Verfahren steht jedem offen — also könnte jeder ein Image signieren und Ihre Regel wäre zufrieden. Eine Türsteher-Regel, die jeden Ausweis akzeptiert, ist kein Türsteher. Diese zwei Zeilen sind der Unterschied zwischen Theater und Kontrolle.

24:42 Fünf Schalter, und die gute Nachricht steht unten: Die drei letzten stehen voreingestellt auf wahr. Die Voreinstellungen sind also streng, und Abschalten ist die bewusste Ausnahme — genau so sollte es sein. Der erste Schalter ist der, über den Sie am meisten nachdenken sollten: Auf welche Images zielt die Regel? Zu eng, und fremde Images kommen ungeprüft durch.

25:03 Zu weit, und Sie sperren die Systemdienste des Clusters aus. Der zweite ist der Einführungsschalter aus dem nächsten Vorgehen. Und der dritte ist die Digest-Ersetzung — sie abzuschalten heißt, wieder bewegliche Tags zuzulassen, und damit die Hälfte des Gewinns aufzugeben. Dieselbe Reihenfolge wie beim Scanner und bei den Profilen: erst berichten, dann erzwingen.

25:26 Neu und wichtig ist Schritt drei, und er ist eine Haltungsfrage: Schließen Sie die Lücken, statt Ausnahmen für sie zu schreiben. Ein unsigniertes Image ist kein Sonderfall, es ist eine offene Aufgabe. Schritt vier ist der Abnahmetest, und der Hinweis darunter sagt es deutlich: Eine Richtlinie, die nichts ablehnt, hat nichts belegt. Probieren Sie es aus.

25:47 Und Schritt fünf ist der unscheinbare Betriebsdetail, das im Ernstfall wehtut: Die Prüfung fragt bei der Registry nach. Ist die langsam, läuft die Zeitüberschreitung ab — und dann verlieren Sie Einreichungen. Diese Übung ist der Abschluss der ganzen Modulkette. Formulieren Sie eine Eintrittsbedingung, die eine belegte Herkunft verlangt, und weisen Sie ihre Wirkung nach.

26:09 Geschafft ist es, wenn Ihr eigenes, signiertes Image im Cluster startet und ein unsigniertes beim Einreichen mit einer verständlichen Meldung abgelehnt wird. Auf das Wort verständlich kommt es an — eine Ablehnung, die niemand versteht, wird umgangen. Wer schneller fertig ist, ergänzt die Prüfung der Stücklisten-Aussage.

26:27 Und lesen Sie die Ablehnungsmeldung gemeinsam: In diesem einen Satz stecken Härtung, Scan, Stückliste, Signatur und Richtlinie — das ganze Modul auf einer Zeile. Der erste Punkt ist der Fehlstart, den Sie unbedingt vermeiden wollen: sofort erzwingen und dabei die Systemdienste des Clusters aussperren. Deren Images kommen von woanders und sind nicht von Ihnen signiert — ein Cluster, der sich selbst nicht mehr starten darf, ist ein unangenehmer Nachmittag.

26:54 Der zweite ist der fehlende Attestor von vorhin: eine beliebige Signatur für einen Nachweis zu halten. Der dritte gibt die Digest-Ersetzung auf und damit die Verbindlichkeit. Und der vierte ist das Betriebsdetail: eine zu knappe Zeitüberschreitung, und bei langsamer Registry verlieren Sie Einreichungen — mit einer Meldung, die nach einem Richtlinienfehler aussieht.

Was ab hier trägt

27:15 Vier Sätze aus diesem Modul. Härtung ist billig — weggenommene Rechte kosten nur Sorgfalt im Bauplan, und sie sind der beste Gegenwert im ganzen Modul. Ein Scan ohne Abbruchbedingung ist Dekoration, kein Prüfschritt. Signiert und geprüft wird über den Digest, denn ein Tag trägt keine Aussage. Und der wichtigste: Erst die Eintrittsbedingung im Cluster macht aus allen Nachweisen eine Wirkung — vorher sind sie Papier. Damit ist die erste Hälfte des Seminars abgeschlossen.

27:43 Im nächsten Modul wechseln wir vollständig die Perspektive und gehen dorthin, wo diese Container am Ende laufen: nach Kubernetes.