Plattform- und Cluster-Security

Plattform- und Cluster-Security

0:00 In Modul 4 haben wir uns um die Sicherheit des Artefakts gekümmert — was steckt im Image, wer hat es gebaut, darf es überhaupt herein. Jetzt kommt die andere Hälfte, und sie betrifft die Plattform selbst: Wer darf im Cluster was? Wer darf mit wem sprechen? Wie hält man zwei Teams auseinander, die sich dieselben Knoten teilen? Und was passiert eigentlich, nachdem ein Container zugelassen wurde?

0:23 Das sind Fragen, die in der Entwicklung gerne beim Betrieb abgelegt werden — und gleichzeitig solche, deren Antworten Sie in Ihren Manifesten schreiben. Sieben Kapitel, von Rechten bis zum Prüfprotokoll.

Rechte vergeben mit RBAC

0:36 Wir beginnen mit den Rechten, und mit einer Eigenschaft, die im ersten Satz der Definition steht und trotzdem ständig übersehen wird — bis jemand versucht, ein Recht wieder wegzunehmen. Es gibt nur Erlauben. Kein Verbieten. Vier Objekte, und das Prinzip dahinter ist eine saubere Trennung: Eine Rolle beschreibt Rechte — sie sagt nicht, wer sie hat.

0:57 Eine Bindung weist sie zu — sie sagt nicht, was sie umfasst. Das ist wie Stellenbeschreibung und Arbeitsvertrag: zwei Dokumente, zwei Zuständigkeiten. Rollen gibt es je Namensraum und clusterweit. Und dann der Satz, den ich Ihnen wirklich einprägen will: Rechte sind ausschließlich additiv. Es gibt keine Verbotsregel, die etwas zurücknimmt. Wer aus Firewalls oder Dateirechten kommt, sucht instinktiv nach einem Verbot — es existiert nicht.

1:25 Sie können nur weniger erlauben, nie etwas verbieten. Eine Regel besteht aus drei Angaben, und die Reihenfolge ist logisch: In welcher Schnittstellengruppe, auf welchen Ressourcen, mit welchen Vorgängen. Hier also Lesen von Pods und ihren Ausgaben — genau das, was ein Entwickler für die Fehlersuche aus Modul 5 braucht, und nicht mehr.

1:45 Zwei Beobachtungen: Die Protokollausgaben sind eine eigene Unterressource, man muss sie also ausdrücklich nennen. Und der Hinweis unten erklärt die leere Angabe, die beim ersten Lesen irritiert: Sie meint die Kerngruppe, und dort liegen die wichtigsten Objekte — Pods, Dienste und Geheimnisse. Hier passiert das Zuweisen, und zwei Dinge sind bemerkenswert.

2:06 Erstens sind die Empfänger eine Liste — dieselbe Rolle kann an Menschen, Gruppen und Dienstkennungen gehen, und in der Praxis bindet man an Gruppen, nicht an Personen. Zweitens, und das überrascht viele: Diese Bindung im Namensraum verweist auf eine Cluster-Rolle. Das ist erlaubt und sogar üblich — der Hinweis unten sagt, warum es funktioniert: Sie gilt dann nur in diesem Namensraum.

2:28 Sie nutzen also die fertige, gepflegte Rollendefinition, beschränken ihre Wirkung aber örtlich. Das erspart Ihnen eine Menge selbst geschriebener Rollen. Vier fertige Rollen, und für den Alltag sind sie überraschend ausreichend. Die erste ist der Generalschlüssel — behandeln Sie sie entsprechend. Interessant ist der Unterschied zwischen der zweiten und dritten: Beide dürfen im Namensraum schreiben, aber nur die zweite darf Rechte weitervergeben.

2:55 Das ist die Trennlinie zwischen „darf arbeiten" und „darf über Zugang entscheiden". Und die vierte hat einen Zusatz, der wichtig ist: Lesen ohne Geheimnisse. Denn Leserechte auf Geheimnisse sind faktisch Vollzugriff auf alle Zugangsdaten des Namensraums. Der Hinweis unten ist ein guter Startpunkt: Für zwei Teams genügen meist die zweite und die vierte.

3:17 Diese drei Befehle sollten Teil jeder Rechteabnahme sein, und der letzte ist der wertvollste. Er fragt nämlich in fremdem Namen: Darf diese Dienstkennung Geheimnisse lesen? Sie müssen sich also nicht anmelden, nicht bitten, nicht vermuten — Sie fragen den Cluster, und er antwortet mit ja oder nein. Der Hinweis unten nennt es den ehrlichsten Weg, eine Rechtevergabe abzunehmen, und ich stimme zu. Denn RBAC ist additiv, und Rechte kommen aus mehreren Bindungen zusammen.

3:45 Was jemand tatsächlich darf, lässt sich aus den Manifesten kaum ablesen — aber genau ausrechnen. Ihre Aufgabe: Rechte nach dem Grundsatz der geringsten Berechtigung vergeben und die Trennung von außen nachweisen. Geschafft ist es, wenn jedes Team seinen Namensraum vollständig verwaltet, den anderen aber nicht sieht — und wenn die Prüfung in fremdem Namen beides bestätigt.

4:07 Auf diesen Nachweis kommt es an; Vermutungen zählen hier nicht, und das ist der Kern der Übung. Wer schneller fertig ist, prüft die voreingestellte Dienstkennung eines Pods. Was sie mitbringt, überrascht viele — und es führt direkt zum nächsten Stolperstein. Der erste Punkt ist die Eigenschaft aus der Definition, jetzt als Erlebnis: Man sucht die Verbotsregel und findet sie nicht, weil es sie nicht gibt.

4:31 Die Lösung ist immer, die zu weite Erlaubnis zu ändern. Der zweite ist ein Tippfehler mit großer Wirkung — eine Cluster-Bindung, wo eine Bindung im Namensraum gemeint war, und Ihre Rolle gilt plötzlich überall. Der dritte ist heimtückisch: Rechte an die voreingestellte Dienstkennung geben heißt, sie jedem Pod im Namensraum zu schenken, auch künftigen.

4:51 Und der vierte ist der Punkt aus der Tabelle: Das Recht auf Geheimnisse ist das Recht auf alle Zugangsdaten.

NetworkPolicies

4:58 Jetzt zum Netz, und hier steht ein Ausgangszustand, der die meisten überrascht: Ohne Regel darf jeder mit jedem sprechen. Jeder Pod erreicht jeden anderen, über Namensräume hinweg, über Teams hinweg. Kubernetes ist offen gebaut — und das ist eine Entscheidung, die Sie kennen müssen. Der erste Satz ist der wichtige: Ohne Regel ist ein Pod nicht isoliert.

5:20 Eine Netzregel wählt dann Pods aus und isoliert sie für eine Richtung — und ab dem Moment gilt: Erlaubt ist nur, was ausdrücklich beschrieben ist. Der Schalter kippt also von „alles offen" auf „alles zu, außer". Mehrere Regeln addieren sich, es gibt keine Reihenfolge und keine Verbotsregel — dieselbe Eigenschaft wie bei den Rechten.

5:39 Und der letzte Satz ist der, der in der Praxis für Enttäuschungen sorgt: Durchgesetzt wird das nicht von Kubernetes, sondern vom Netz-Baustein des Clusters. Kubernetes nimmt die Regel an, egal ob jemand sie umsetzt. Das ist eine der elegantesten Konstruktionen in Kubernetes, und sie besteht praktisch aus zwei leeren Klammern.

5:59 Eine leere Auswahl bedeutet nämlich nicht „niemand", sondern „alle Pods" — und weil keine einzige Erlaubniszeile darunter steht, ist nichts erlaubt. Sie haben also mit sieben Zeilen den Namensraum abgedichtet. Genau so beginnt man, weil man dann bewusst öffnet, statt hinterher zu suchen. Aber lesen Sie den zweiten Satz des Hinweises: Die Namensauflösung muss danach eigens freigegeben werden.

6:21 Das ist der Klassiker, dem gleich noch ein eigener Stolperstein gewidmet ist — und der Grund für viele ratlose Nachmittage. Und hier die Gegenbewegung: eine einzige erlaubte Verbindung. Lesen Sie das Manifest als Satz — Pods mit dem Datenbank-Label nehmen eingehenden Verkehr an, und zwar nur von Pods mit dem API-Label, und nur auf diesem einen Port.

6:42 Genau so sollte Netzwerkbeschreibung aussehen: nachlesbar und begründbar. Und der Hinweis unten macht auf etwas aufmerksam, das Ihnen jetzt vertraut sein sollte: Wieder tragen Labels die Auswahl — dieselbe Mechanik wie bei den Diensten in Modul 5. Das ist eines der schönen Merkmale von Kubernetes: Ein Mechanismus, viele Anwendungen. Wer Labels beherrscht, beherrscht die halbe Plattform.

7:06 Fünf Fragen, und drei davon räumen mit Erwartungen auf. Die erste ist die wichtigste und gehört auf den ersten Cluster-Tag: Ohne passenden Netz-Baustein bleibt die Regel wirkungslos — angenommen, gespeichert, ohne Effekt. Fragen Sie das nach, bevor Sie eine Netzarchitektur entwerfen. Die dritte begrenzt die Erwartung: Es geht um Adressen und Ports, nicht um Inhalte — dafür bräuchte es ein Dienstnetz.

7:30 Und die fünfte ist die gute Nachricht: Antwortverkehr ist eingeschlossen, Sie müssen ihn nicht eigens erlauben. Der Hinweis unten nennt zwei beruhigende Grenzen: Ein Pod kann sich nie selbst aussperren, und der Verkehr zum eigenen Knoten bleibt erlaubt. Das Lernziel enthält eine Formulierung, die mir gefällt: jeden erlaubten Weg begründen.

7:50 Denn das ist der Unterschied zwischen einer Netzarchitektur und einer Sammlung von Ausnahmen. Kommen Sie vom offenen Ausgangszustand zu einer beschriebenen Erreichbarkeit. Der Erfolg hat drei Teile, und der dritte steht mit Absicht dort: Die Namensauflösung funktioniert weiter. Sie ist nämlich der Klassiker unter den vergessenen Freigaben, und genau deshalb steht sie im Erfolgskriterium.

8:13 Wer schneller fertig ist, prüft, welche ausgehenden Verbindungen die Anwendung wirklich braucht. Diese Liste ist meist kürzer, als alle glauben. Der erste Punkt ist die vergessene Namensauflösung, und ihr Fehlerbild ist besonders verwirrend: Jeder Aufruf läuft in eine Zeitüberschreitung, ohne Fehlermeldung, ohne abgewiesene Verbindung — es ist einfach still.

8:34 Der zweite ist der aus der Tabelle und der gefährlichste, weil er ein Sicherheitsgefühl erzeugt, das nicht gedeckt ist: Regeln schreiben, die niemand durchsetzt. Der dritte ist eine halbe Absicherung — nur den Eingang zu regeln lässt einen übernommenen Pod nach draußen telefonieren. Und der vierte ist die Verbotsregel-Suche aus Kapitel 1, jetzt im Netz: Sie existiert auch hier nicht.

Regeln jenseits der Signatur

8:56 In Modul 4 haben wir eine Eingangsprüfung installiert und ihr genau eine Frage gestellt: Ist das Image signiert? Dieses Werkzeug kann erheblich mehr — und damit wird aus betrieblichen Vorgaben etwas Überprüfbares. Compliance als Objekt im Cluster. Dasselbe Werkzeug prüft beliebige Eigenschaften, ergänzt fehlende Angaben und erzeugt begleitende Objekte.

9:18 Das ist mehr als eine Erweiterung — es bedeutet, dass Sie „unsere Pods müssen Ressourcenangaben haben" nicht mehr in ein Wiki schreiben, sondern in eine Regel. Aus einer Bitte wird eine Bedingung. Daneben steht ein zweiter verbreiteter Weg, der Regeln in einer eigenen Regelsprache formuliert; dazu gleich der Vergleich. Und ein pragmatischer Hinweis zum Schluss: Für Profile bleibt die eingebaute Prüfung aus Modul 4 der einfachste Weg.

9:44 Nehmen Sie nicht das große Werkzeug für etwas, das vier Labels erledigen. Diese Regel setzt genau das durch, was wir in Modul 5 als gute Praxis besprochen haben — Anforderungen und Grenzen an jedem Container. Und beachten Sie das Muster: Die Regel beschreibt die geforderte Struktur, nicht eine Bedingung. Sie sagt, wie das Manifest aussehen muss, und das liest sich für jemanden, der Manifeste kennt, angenehm vertraut.

10:09 Der Hinweis unten erklärt das Fragezeichen mit Stern: Es verlangt einen beliebigen, aber nicht leeren Wert. Und noch etwas lohnt Aufmerksamkeit — die Meldung. Schreiben Sie sie sorgfältig, denn sie ist das Einzige, was die Kollegin nachher liest. Drei Arten, und sie unterscheiden sich in ihrer Eingriffstiefe. Prüfen ist die harmloseste und die, mit der man beginnt.

10:32 Erzeugen legt begleitende Objekte an, etwa eine Netzregel für jeden neuen Namensraum — sehr praktisch für Plattformteams. Und Ergänzen verdient die Warnung, die der Hinweis unten ausspricht: Es ist bequem und heikel, weil das, was das Werkzeug einsetzt, in keinem Repository steht. Damit haben Sie eine unsichtbare Quelle für Ihren Cluster-Zustand — und die widerspricht direkt dem GitOps-Gedanken aus Modul 6, wo das Repository die Wahrheit sein sollte.

10:58 Nutzen Sie es sparsam und dokumentiert. Zwei Werkzeuge, und die erste Zeile entscheidet in der Praxis meistens: Regeln in YAML wie Manifeste, oder Regeln in einer eigenen Sprache. Das eine ist für ein Team ohne Spezialisten sofort zugänglich, das andere braucht Einarbeitung und ist dafür ausdrucksstärker — es kann Regeln formulieren, die im Musterabgleich unbequem werden.

11:20 Meine Einordnung für den Einstieg: Nehmen Sie den flachen Weg, bis Sie an eine Grenze stoßen. Und lesen Sie den Hinweis unten, weil er den letzten Stolperstein vorwegnimmt: Beides sind Eingangsprüfungen am selben Dienst, und mehrere gleichzeitig zu betreiben lohnt selten. Zum Ordnen, denn wir haben inzwischen drei Mechanismen und sie werden gerne verwechselt.

11:41 Die eingebaute Prüfung deckt Profile ab, kostenlos und ohne Zusatzbaustein — nehmen Sie sie für alles, was sie kann. Alles Weitere — Signaturen, Ressourcen, Namensschemata — braucht Regeln. Und RBAC beantwortet eine völlig andere Frage: wer etwas darf, nicht wie es aussehen muss. Diese Unterscheidung ist wichtig, weil sie erklärt, warum ein berechtigter Nutzer ein schlechtes Manifest einreichen kann — RBAC prüft die Person, die Regel prüft den Inhalt.

12:09 Erst zusammen ergeben sie eine Aussage über jede eingereichte Beschreibung. Ihre Aufgabe: eine betriebliche Anforderung als Eingangsbedingung formulieren und ihre Wirkung an einem Gegenbeispiel belegen. Auf das Gegenbeispiel kommt es an — eine Regel, die nie etwas abweist, ist nicht erprobt. Geschafft ist es, wenn ein Pod ohne Ressourcenangaben mit verständlicher Meldung abgewiesen wird, ein vollständiger läuft, und der Bestand vorher berichtend geprüft war.

12:37 Wer schneller fertig ist, ergänzt eine Regel für ein verbindliches Namensschema der Labels — das ist die Verabredung aus Modul 5, jetzt durchgesetzt. Und die Reihenfolge bleibt: erst berichtend, dann erzwingend. Wie bei allen Eingangsprüfungen. Der erste Punkt ist die Reihenfolge, und ich nenne ihn zum vierten Mal in diesem Seminar, weil er zum vierten Mal richtig ist: erzwingend eingeführt ohne Bestandsprüfung, und der Betrieb steht.

13:02 Der zweite ist der schnellste Weg, einen Cluster lahmzulegen: Systemnamensräume nicht ausnehmen. Deren Pods erfüllen Ihre Regeln nämlich nicht, und ohne sie startet nichts. Der dritte ist die unsichtbare Quelle aus der Tabelle. Und der vierte ist ein Diagnosealbtraum, den man vermeiden sollte: zwei Eingangsprüfungen mit widersprüchlichen Regeln — die eine ergänzt, was die andere abweist, und die Meldung erklärt es nicht.

Geheimnisse von außen holen

13:27 Jetzt lösen wir einen Widerspruch auf, der in Modul 6 offen geblieben ist. Modul 5 hat gezeigt: Ein Secret ist nur kodiert. Modul 6 hat gesagt: Der Soll-Zustand gehört ins Repository. Zusammen ergibt das ein Problem — und die Lösung ist eine Richtungsumkehr. Das Geheimnis lebt im Tresor, nicht im Repository. Die Lösung dreht die Richtung: Im Repository steht nur ein Verweis, und ein Baustein im Cluster holt den Wert aus einem Tresor.

13:56 Das Bild dazu ist ein Bankschließfach — im Adressbuch steht die Fachnummer, nicht der Inhalt. Und was der Baustein daraus macht, ist der elegante Teil: ein gewöhnliches Secret, wie es in Modul 5 stand. Ihre Anwendung merkt vom Tresor nichts, sie liest wie immer eine Umgebungsvariable oder eine Datei. Nachgezogen wird in festem Takt, was zwei Dinge bedeutet: Ein gewechseltes Kennwort kommt von selbst an, und ein gelöschtes Secret wird ersetzt.

14:23 Sehen Sie sich dieses Manifest daraufhin an, was fehlt: Es enthält kein Geheimnis. Nur eine Adresse im Tresor, einen Schlüsselnamen und ein Ziel. Genau deshalb steht in der Beschriftung „im Repository unbedenklich" — dieses YAML darf öffentlich sein. Der Takt von einer Stunde ist ein guter Startwert; er ist die Antwortzeit auf einen Kennwortwechsel.

14:44 Und der Hinweis unten nennt noch einmal die Pointe, die dieses Verfahren so gut einsetzbar macht: Am Ende entsteht ein gewöhnliches Secret. Sie müssen also keine Anwendung anpassen — das ist der Grund, warum sich dieser Weg nachträglich einführen lässt. Drei Wege, und sie sind absteigend sortiert. Der erste ist der empfohlene und verlangt einen Tresor — organisatorisch also die größte Vorbedingung.

15:08 Der zweite verschlüsselt den Wert direkt im Repository, was ohne Tresor auskommt und attraktiv wirkt. Lesen Sie dazu aber den Hinweis unten, denn er beschreibt ein echtes Risiko: Alles hängt am Schlüsselpaar im Cluster. Geht es verloren — beim Neuaufbau, bei einem Wiederherstellungsfehler — ist nichts mehr entschlüsselbar, und Ihr Repository ist voller unlesbarer Werte.

15:30 Der dritte Weg ist der Vollständigkeit wegen aufgeführt: keine Voraussetzung, und keine Sicherheit. Vier Punkte, und der erste ist der, der den Betrieb überzeugt: Ein Kennwortwechsel geschieht im Tresor — kein Zweig, kein Review, keine Zusammenführung. Bei einem Sicherheitsvorfall um zwei Uhr nachts ist das ein erheblicher Unterschied.

15:50 Der zweite ist Rechtefeinheit: Wer den Tresor lesen darf, ist dort genauer steuerbar als über Repository-Rechte. Der dritte ist der, den man erst später schätzt und der nicht rückwirkend zu bekommen ist: Der Verlauf des Repositorys enthält nie einen gültigen Wert. Und der vierte macht abgelaufene Werte selbstheilend — der Takt zieht sie einfach nach.

16:11 Der erste Punkt ist der schönste Zirkelschluss in diesem Modul: Man richtet den Tresor ein, um Klartext-Geheimnisse zu vermeiden — und hinterlegt den Zugang zum Tresor als Klartext-Secret. Damit ist nichts gewonnen. Der Ausweg ist eine Anmeldung über die Identität des Clusters, ohne hinterlegtes Kennwort. Der zweite ist eine Taktfrage mit Nebenwirkung: sehr kurz gesetzt, überziehen Sie den Tresor mit Anfragen, und manche Anbieter rechnen das ab.

16:37 Der dritte ist der Schlüsselverlust aus der Tabelle. Und der vierte ist eine Erwartungskorrektur: Das Ergebnis ist ein gewöhnliches Secret — Leserechte darauf bleiben nötig und wirken wie immer.

Laufzeitüberwachung mit Falco

16:49 Jetzt eine Lücke, die Sie vielleicht schon gespürt haben. Alle Prüfungen dieses Seminars — Signaturen, Profile, Regeln — wirken vor dem Start. Und danach? Danach war bisher Stille. Die Frage dieses Kapitels: Was tut der Container, nachdem er zugelassen wurde? Eingangsprüfungen entscheiden einmal, beim Einreichen — das ist der Türsteher. Was danach im Club passiert, sieht er nicht.

17:14 Eine Laufzeitüberwachung beobachtet, was Prozesse tatsächlich tun: welche Aufrufe sie an den Kern richten, welche Dateien sie öffnen, welche Verbindungen sie aufbauen. Und der technisch interessante Teil ist die Quelle: Die Ereignisse kommen aus dem Kern selbst, über ein Kernmodul oder eine eBPF-Sonde. Das lässt sich aus dem Container heraus nicht umgehen und nicht fälschen — anders als eine Meldung, die die Anwendung selbst schreibt.

17:39 Gehalten werden diese Ereignisse dann gegen Regeln. Diese Regel ist ein gutes Beispiel, weil sie so lesbar ist: Wenn ein Prozess gestartet wird, und es passiert in einem Container, und der Prozessname ist eine Shell — dann melde das. Man kann solche Regeln lesen, ohne die Sprache gelernt zu haben, und das ist bei Sicherheitswerkzeugen keine Selbstverständlichkeit.

18:01 Der Hinweis unten schließt einen hübschen Bogen zu Modul 4: Bei einem gehärteten Image gibt es gar keine Shell. Diese Meldung wäre dort also nicht nur ein Hinweis, sondern ein sehr starkes Signal — jemand hat eine Shell mitgebracht. Härtung und Überwachung verstärken einander. Der erste Punkt ist der Zugewinn: Sie erkennt Verhalten, das keine Beschreibung vorher verbieten konnte — weil man nicht weiß, was man nicht weiß.

18:25 Die anderen drei sind Einschränkungen, und ich nenne sie deutlich. Sie meldet, sie verhindert nicht; die Reaktion ist ein eigener Schritt, den Sie bauen müssen. Sie kostet Rechenzeit auf jedem Knoten, weil sie überall mitläuft — auf großen Knoten ist das messbar. Und der vierte Punkt ist der ernüchterndste: Ohne Empfänger für die Meldungen ist sie ein Protokoll, das niemand liest.

18:47 Klären Sie den Empfänger, bevor Sie das Werkzeug installieren. Der erste Punkt ist der Grund, warum viele Installationen nach vier Wochen abgeschaltet werden: Der mitgelieferte Regelsatz ist breit angelegt, und unverändert betrieben ertrinken Sie in Falschmeldungen. Nehmen Sie sich die Zeit, ihn auf Ihre Anwendungen zuzuschneiden. Der zweite ist der fehlende Empfänger aus dem Warum.

19:10 Der dritte ist eine Erwartung, die man korrigieren muss, gerade gegenüber der Geschäftsführung: Sie beobachtet, sie unterbindet nicht. Und der vierte ist ein Kapazitätsthema, das man vorher rechnen sollte: Auf großen Knoten entzieht die Überwachung der Anwendung Rechenzeit — und zwar dort, wo die Last ohnehin hoch ist.

Sichern und Wiederherstellen

19:28 Jetzt zu dem Punkt, an dem GitOps allein nicht mehr reicht — und das ist eine wichtige Einsicht, weil Modul 6 so überzeugend geklungen hat. Der Cluster ist beschrieben, ja. Die Daten sind es nicht. Aus dem Repository entsteht der beschriebene Zustand wieder — jedes Deployment, jeder Service, jede Regel. Aber nicht der Inhalt der Datenträger.

19:49 Ihre Datenbank steht in keinem Git, und das ist gut so. Eine Sicherung im Cluster nimmt daher zwei Dinge mit: die Objekte aus der Datenbank der Steuerungsebene und die Daten der beständigen Datenträger. Und passend zu allem, was wir gelernt haben, wird sie selbst als Objekt beschrieben — samt Zeitplan, Aufbewahrungsdauer und Auswahl der Namensräume.

20:10 Kein Skript auf einem Server, das niemand kennt, sondern ein Objekt im Cluster. Zwei Befehle für zwei Anlässe. Der erste sichert sofort — das ist der Griff vor einem Eingriff, und ich empfehle, ihn sich anzugewöhnen: vor jedem größeren Umbau eine Sicherung mit dem Datum im Namen. Der zweite legt einen Zeitplan an, hier nachts um zwei.

20:30 Beachten Sie die Aufbewahrung von hundertachtundsechzig Stunden, also einer Woche, und lesen Sie den Hinweis unten genau: Läuft die Aufbewahrung ab, verschwinden Sicherung, Dateien und Datenträgerabbilder zusammen. Das ist konsequent und im Ernstfall bitter — wer nach zehn Tagen feststellt, dass er etwas braucht, findet es nicht mehr.

20:50 Vier Bestandteile, und die dritte Zeile ist ein wichtiger Ausweg: Wo der Speicher keine Abbilder kann, wird dateiweise gesichert. Das ist langsamer und funktioniert. Fragen Sie Ihren Speicheranbieter, bevor Sie die Sicherungsstrategie festlegen. Die vierte Zeile passt zur Definition — Zeitplan und Aufbewahrung sind eigene Objekte, keine Skripte.

21:10 Und dann steht unten ein Satz, den man nicht übersehen darf: Eine Sicherung ist ausdrücklich nicht atomar. Was während des Laufs entsteht, kann fehlen. Für eine Datenbank heißt das: Nutzen Sie die Sicherungsverfahren der Datenbank selbst — hier geht es um die Plattform, nicht um Transaktionen. Das Wort wirklich steht mit Absicht in der Überschrift. Belegen Sie die Brauchbarkeit Ihrer Sicherung durch eine Wiederherstellung — nicht durch ihre Existenz.

21:38 Geschafft ist es, wenn ein gelöschter Namensraum samt Datenbankinhalt wiederhergestellt ist und die Anwendung mit den Daten von vor dem Löschen antwortet. Wer schneller fertig ist, stellt in einen anderen Namensraum wieder her und erklärt, was dabei angepasst werden muss — eine sehr lehrreiche Übung. Und der Satz aus der Notiz gilt für dieses Kapitel und für Ihren Betrieb: Eine ungeprüfte Sicherung ist keine Sicherung. Das ist der einzige Satz, der hier zählt.

22:04 Der erste Punkt ist laut Folie der häufigste Fehler im ganzen Modul, und meine Erfahrung bestätigt das: sichern und nie wiederherstellen. Der Sicherungsauftrag läuft grün, jahrelang — und im Ernstfall stellt sich heraus, dass etwas fehlt. Der zweite ist die halbe Sicherung: nur Objekte, keine Datenträger. Aus dem Repository hätten Sie die Objekte ohnehin bekommen.

22:25 Der dritte ist ein Denkfehler, der bei regionalen Ausfällen zuschlägt: die Sicherung im selben Ausfallbereich wie der Cluster. Und der vierte ist eine Kostenfalle — ohne Aufbewahrungsdauer füllt sich der Objektspeicher unbegrenzt, und es fällt erst auf der Rechnung auf.

Cluster-Updates und Prüfprotokoll

22:42 Zum Abschluss zwei Pflichten, die niemand freiwillig übernimmt — Updates und Prüfprotokoll. Beide sind unspektakulär, beide werden aufgeschoben, und beide sind genau die, die im Ernstfall zählen. Nehmen wir sie ernst, es sind nur ein paar Regeln. Die erste Regel ist absolut: Ein Cluster darf beim Aktualisieren keine Nebenversion überspringen.

23:03 Von 1.31 auf 1.33 in einem Schritt ist nicht unterstützt, auch wenn es zu funktionieren scheint. Dazu kommen begrenzte Versionsabstände zwischen den Bauteilen: Die Knotendienste dürfen bis zu drei Nebenversionen hinterherlaufen, Steuerungsregler und Planer nur eine, und das Bedienwerkzeug darf eine darüber oder darunter liegen.

23:23 Und der letzte Satz ist die Merkregel, die alles zusammenhält: Neuer als der Schnittstellendienst darf nichts sein. Er ist das Nadelöhr, also aktualisiert man ihn zuerst. Diese Zahlen muss man nicht auswendig kennen, aber die Ordnung dahinter lohnt sich: Je weiter ein Bauteil vom Schnittstellendienst entfernt ist, desto mehr Abstand ist erlaubt.

23:43 Die Knotendienste haben viel Spielraum, weil man Hunderte Knoten nicht gleichzeitig aktualisiert. Regler und Planer sitzen daneben und haben fast keinen. Der Hinweis unten ist die betrieblich wichtigste Zeile der Folie, denn er bestimmt Ihren Kalender: Gepflegt werden drei Nebenversionen gleichzeitig, jede rund ein Jahr.

24:01 Sie müssen also etwa dreimal im Jahr aktualisieren — wer das aufschiebt, landet außerhalb der Unterstützung und braucht dann mehrere Schritte hintereinander. Jetzt das Prüfprotokoll, und der zweite Satz ist der, den man wissen muss: Es ist nicht voreingestellt aktiv. Viele Teams gehen davon aus, dass irgendwo mitgeschrieben wird — es wird nicht, es braucht eine Richtlinie und einen Schalter am Dienst.

24:24 Die Richtlinie ordnet dann jeder Anfrage eine Ausführlichkeit zu, von gar nicht über Kopfdaten bis zu Anfrage und Antwort im Wortlaut. Und der letzte Satz ist die Mechanik, die Sie beim Schreiben beachten müssen: Die erste passende Regel gewinnt. Reihenfolge ist also bedeutsam — anders als bei Rechten und Netzregeln, wo sich alles addierte.

24:45 Diese Richtlinie ist ein gutes Muster, weil sie das Mengenproblem löst. Die erste Regel wirft Ereignisse ganz heraus — davon gibt es unzählige, und sie sagen sicherheitlich nichts. Die zweite protokolliert Geheimniszugriffe im vollen Wortlaut, denn genau das will man später nachlesen können. Und die dritte Regel hat keine Auswahl, fängt also alles Übrige auf Kopfdatenebene auf. Lesen Sie den Hinweis dazu: Ohne diese letzte Regel fiele der ganze Rest heraus.

25:12 Das ist die Konsequenz aus „die erste passende Regel gewinnt" — was auf keine Regel passt, wird nicht protokolliert. Vier Stufen, und für den Alltag ist die zweite die richtige: wer, wann, welches Objekt, welcher Vorgang. Das ist die Frage, die eine Revision stellt, und sie ist mengenmäßig beherrschbar. Die beiden oberen Stufen nehmen Inhalte mit und lassen das Protokoll erheblich wachsen.

25:35 Und dann steht unten ein Satz, der eine Sicherheitsfalle beschreibt, die man kennen muss: Die höchste Stufe auf Geheimnisse angewandt schreibt deren Werte ins Protokoll. Wer also alles maximal mitschreibt, hat plötzlich sämtliche Kennwörter im Klartext in einem Protokoll, das oft weniger geschützt ist als der Cluster selbst.

25:53 Bewusst wählen — das gilt hier wörtlich. Fünf Schritte, und der Hinweis unten benennt richtig, welcher wehtut: Schritt zwei, die eigenen Manifeste gegen entfernte Schnittstellen prüfen. Denn Kubernetes entfernt Schnittstellenfassungen, und Ihre zwei Jahre alten Manifeste verweisen womöglich auf eine davon. Fällt das nicht vorher auf, fällt es im Betrieb auf.

26:15 Schritt eins liefert dafür die Liste — die Hinweise zur Zielversion nennen sie ausdrücklich. Schritt drei ist die Sicherung aus dem letzten Kapitel, und zwar eine geprüfte. Schritt vier ist die Reihenfolge aus der Merkregel: Steuerungsebene zuerst. Und Schritt fünf ist die absolute Regel: eine Nebenversion je Schritt. Der erste Punkt ist die absolute Regel in Negativform: eine Nebenversion übersprungen, und Sie sind in einem nicht unterstützten Update — es mag laufen, und im Fehlerfall hilft Ihnen niemand.

26:45 Der zweite verletzt die Merkregel: Knoten vor der Steuerungsebene aktualisiert, und plötzlich ist ein Bauteil neuer als der Schnittstellendienst. Der dritte ist die Kennwortfalle aus der Tabelle, und ich wiederhole sie, weil sie so still passiert. Und der vierte ist der, der mich am meisten beschäftigt, weil er so verbreitet ist: Ein Protokoll führen, das niemand auswertet, und es für Sicherheit halten.

27:07 Es ist dann nur eine Aufzeichnung.

Was ab hier trägt

27:09 Vier Sätze aus diesem Modul. Rechte sind nur additiv — es gibt kein Verbot, das eine Erlaubnis zurücknimmt, und dasselbe gilt im Netz. Ohne Netzregel spricht jeder mit jedem; Isolation beginnt mit „alles zu" und wird dann bewusst geöffnet. Geheimnisse gehören in den Tresor, ins Repository nur ihr Verweis. Und eine Sicherung, die nie wiederhergestellt wurde, ist keine Sicherung.

27:34 Im letzten Modul kommt alles zusammen, und wir gehen dorthin, wo Kubernetes derzeit am schnellsten wächst: GPU-Workloads und LLM-Inferenz. Andere Hardware, andere Startzeiten, andere Kosten — und dieselben Prinzipien.