kubernetes-minimal-on-a-vm

🛠️🚧❓Security-Advice: Die Inhalte dieses Repositorys sind Ergebnisse und Gegenstand von Tests und Veränderungen. Sie können deshalb nur in diesem Sinne verwendet werden. Texte zwischen den Bot-Markern 🤖▶️ und 🤖◀️ können KI-generierte Bestandteile enthalten.

🤖▶️

Entstanden im ZKI-Arbeitskreis Informationssicherheit als Erprobungsfall dafür, wie sich Aussagen nach BSI Grundschutz++ an einem laufenden System nachprüfbar machen lassen.

Drei Skripte und ein paar Manifeste, die aus einer leeren virtuellen Maschine einen einzelnen Kubernetes-Knoten machen: gehaertetes Betriebssystem, k3s mit verschlüsselten Secrets, cert-manager mit Let's Encrypt, ArgoCD fuer GitOps, Kyverno mit den Richtlinien der Interessengemeinschaft Betrieb von Containern, auf Wunsch Velero fuer Sicherungen.

Der Unterschied zu anderen Baukaesten liegt nicht im Umfang, sondern in der Nachpruefbarkeit. Zu jedem Aufbau gehoeren zwei Proben: eine liest die Einstellungen, die andere versucht jeweils das, was nicht gehen soll — ein Image mit Tag statt Digest starten, aus einem fremden Namensraum an die Datenbank, den Inhalt eines Secrets im Klartext in der Datenbank finden. Bestanden ist, was scheitert. Der Unterschied zwischen "die Richtlinie steht da" und "die Richtlinie greift" ist der Kern dieses Projekts.

Die Plattform verwaltet sich selbst aus Git: cert-manager, ArgoCD und Kyverno liegen als Kustomize-Zusammenstellungen im Repo, mit Digest, Pod-Security-Stufe und Ressourcengrenzen an der Quelle. Was am laufenden Cluster von Hand geaendert wird, verschwindet beim naechsten Abgleich.

Was der Aufbau nicht leistet, steht benannt in RESTRISIKEN.md: Ein einzelner Knoten faengt keinen Ausfall auf, und zwei Einstellungen lassen sich an einem laufenden Cluster nicht nachruesten. Was der CIS-Benchmark bei k3s meldet und was davon zaehlt, steht in KUBE-BENCH.md. Der Aufbau wird ausserdem gegen den Grundschutz++-Anwenderkatalog des BSI gemessen; die Ergebnisse liegen oeffentlich im Projekt it-grundschutz derselben Gruppe.

🤖◀️