Cluster vor dem Go-live von außen prüfen lassen? Das Cluster-Audit prüft Konfiguration, Versionen, Zugriffe, Netzwerk-Richtlinien und Backups Ihres Clusters und liefert einen Bericht mit priorisierten Maßnahmen. Ab 1.490 € netto einmalig, anrechenbar auf den ersten Betriebsmonat, kein Penetrationstest (Stand Oktober 2026). Cluster-Audit ansehen
Ein Cluster, der Deployments annimmt, ist noch nicht produktionsreif. Diese Checkliste ist ein Selbsttest mit 25 Prüfpunkten in sechs Bereichen. Jeder Punkt hat ein Bestehenskriterium, das sich messen oder vorführen lässt, und eine Bewertung: grün, gelb oder rot. Alle roten Punkte werden vor dem Go-live geschlossen. Stand Oktober 2026. Sie ist kein Penetrationstest.
Inhaltsverzeichnis
- So funktioniert die Bewertung
- Die 25 Prüfpunkte
- Reihenfolge der Prüfung
- Prüfbefehle
- Welche Kubernetes-Version für das Go-live
- Wann der Selbsttest nicht reicht
- Unser Vorgehen bei WZ-IT
- Stand und Methodik
- Weiterführende Guides
So funktioniert die Bewertung
Jeder Punkt bekommt eine Farbe:
- Grün: Das Kriterium ist erfüllt und mit einem Nachweis belegt (Befehlsausgabe, Protokoll oder Bericht mit Datum).
- Gelb: Das Kriterium ist teilweise erfüllt, zum Beispiel in einem Namespace statt in allen, oder erfüllt, aber nicht belegt.
- Rot: Das Kriterium ist nicht erfüllt oder unbekannt. Unbekannt zählt wie nicht erfüllt.
| Ergebnis | Entscheidung |
|---|---|
| Mindestens ein roter Punkt | Kein Go-live. Die roten Punkte schließen und die Prüfung der betroffenen Punkte wiederholen. |
| Keine roten, einzelne gelbe Punkte | Go-live möglich. Jeder gelbe Punkt erhält einen Verantwortlichen und einen Termin im Maßnahmenplan. |
| Alle Punkte grün | Go-live. Das Protokoll mit Datum, Prüfer und Nachweisen ablegen. |
Eine zweite Person bestätigt die Farben. Wer die Architektur entschieden hat, prüft sie mit denselben Annahmen. Die Prüfung wird vor jedem Minor-Upgrade und nach größeren Änderungen an Zugriffen, Netzwerk oder Storage wiederholt.
Die 25 Prüfpunkte
A Verfügbarkeit
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| A1 | Control Plane redundant | Mindestens 3 Control-Plane-Nodes (etcd läuft mit einer ungeraden Zahl von Mitgliedern, die Dokumentation empfiehlt für Produktion fünf). Bei abgeschaltetem Node antwortet /readyz des API-Servers mit HTTP 200 (Health-Endpunkte). Managed: Verfügbarkeitszusage des Anbieters liegt vor. |
| A2 | Kapazität für einen Node-Ausfall | Nach kubectl drain des am höchsten belasteten Nodes sind alle Pods wieder Ready, kein Pod bleibt Pending (Drain). |
| A3 | Replikas und Verteilung | Jede produktive Anwendung, auch der Ingress-Controller, läuft mit mindestens 2 Replikas auf verschiedenen Nodes (Topology Spread) und hat ein PodDisruptionBudget. Single-Instance-Ausnahmen sind dokumentiert. |
| A4 | Health Checks | 0 Container in Produktions-Namespaces ohne readinessProbe. Langsam startende Anwendungen haben eine startupProbe (Probes, BSI APP.4.4 A11). |
B Ressourcen und Skalierung
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| B1 | Requests und Limits | 0 Container ohne CPU- und Memory-Request und ohne Memory-Limit. Das Memory-Limit liegt nicht über dem Request, sonst drohen OOM-Probleme auf dem ganzen Node (Security Checklist, SYS.1.6.A15). |
| B2 | Quota und LimitRange | Jeder Produktions-Namespace hat eine ResourceQuota und einen LimitRange. |
| B3 | Skalierung und Reserve | Lastabhängige Dienste haben einen HorizontalPodAutoscaler mit Metrikquelle, kein Target steht auf <unknown>. Die Summe der Requests liegt im Normalbetrieb unter 70 % der zuweisbaren Kapazität. |
| B4 | Lasttest | Die erwartete Spitzenlast mal 1,5 läuft ohne OOMKilled, ohne Pending-Pods und mit p95-Latenz im Ziel. Das Protokoll trägt ein Datum. |
C Betrieb, Monitoring und Alarmierung
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| C1 | Metriken vollständig | Die Zahl der Nodes im Monitoring entspricht der Zahl im Cluster. API-Server, etcd, kubelet und alle produktiven Namespaces sind enthalten. |
| C2 | Alarme mit Empfänger | Alarmregeln bestehen für Node NotReady, CrashLoopBackOff, volle Volumes, ablaufende Zertifikate, Fehlerrate des API-Servers und fehlgeschlagene Backups. Jeder Alarm wurde als Test ausgelöst und kam beim benannten Empfänger an. |
| C3 | Logs außerhalb des Clusters | Die Logzeile eines gelöschten Pods ist weiterhin abrufbar (SYS.1.6.A7 verlangt Container-Logs außerhalb des Containers). Die Aufbewahrungsfrist ist festgelegt. |
| C4 | Zertifikate | Alle Zertifikate sind erfasst und laufen frühestens in 30 Tagen ab. Die Erneuerung ist automatisiert oder alarmiert. Von kubeadm erzeugte Zertifikate gelten standardmäßig ein Jahr, die CA-Zertifikate zehn Jahre. |
D Backup und Restore
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| D1 | Umfang | Für jeden Posten aus APP.4.4 A5 besteht ein Sicherungsjob oder eine begründete Ausnahme: Persistent Volumes, Konfiguration der Control Plane, Clusterzustand, etcd, Infrastrukturanwendungen, Registry-Daten. |
| D2 | Ziel und Trennung | Das Backup-Ziel liegt außerhalb des Clusters, mit eigenen Zugangsdaten. Aufbewahrung und Verschlüsselung der Sicherungen sind festgelegt. |
| D3 | Datenbank-Restore | Die größte Datenbank wurde in eine leere Umgebung zurückgespielt. Gemessene Dauer und Datenstand liegen innerhalb der vereinbarten Ziele (RTO, RPO). Das Protokoll ist höchstens 90 Tage alt. |
| D4 | Wiederaufbau | Aus leerem Cluster, Backup und Git laufen alle produktiven Anwendungen wieder. Die gemessene Dauer liegt unter dem vereinbarten Ziel. |
E Sicherheit
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| E1 | Zugriffe | Anmeldung über Identity Provider. Jede cluster-admin-Bindung ist begründet, kein Konto gehört zu system:masters. Der RBAC-Export mit Datum liegt vor. |
| E2 | Pod Security | kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce' liefert keine Namespaces. Anwendungs-Namespaces stehen auf restricted, Ausnahmen auf baseline sind begründet. |
| E3 | Netzwerk | 0 produktive Namespaces ohne NetworkPolicy, Default-Deny für Ingress aktiv. Der API-Server ist von außen nicht erreichbar, getestet aus einem fremden Netz. |
| E4 | Secrets | Verschlüsselung im etcd aktiv (Test: der in etcd gespeicherte Wert beginnt mit k8s:enc:). Keine Zugangsdaten in Git oder Images. |
| E5 | Version und Images | Das Support-Ende der Version liegt mindestens 6 Monate nach dem Go-live oder ein Upgrade-Termin steht fest. Der Image-Scan zeigt keine offenen kritischen Befunde ohne dokumentierte Ausnahme. |
Die Prüfkriterien zu E1 bis E5 stehen mit Befehlen und Normbezug in der Härtungs-Checkliste.
F Prozesse und Übergabe
| Nr. | Prüfpunkt | Bestanden, wenn |
|---|---|---|
| F1 | Runbooks | Runbooks bestehen für Node-Ausfall, CrashLoop, volles Volume, abgelaufenes Zertifikat und Restore. Eine Person, die den Cluster nicht gebaut hat, löst „Node-Ausfall“ damit im Test. |
| F2 | Upgrade geübt | Ein Minor-Upgrade lief auf einem Staging-Cluster mit gleicher Topologie. Dauer und Rückweg sind protokolliert, das Wartungsfenster ist vereinbart (SYS.1.6.A2 verlangt Updates in der Planung des Lebenszyklus). |
| F3 | Besetzung und Erreichbarkeit | Mindestens 2 benannte Personen können Restore und Upgrade ausführen. Eskalationsweg und Reaktionszeit stehen schriftlich. Ein Testalarm außerhalb der Bürozeit wird innerhalb der vereinbarten Zeit bearbeitet. |
| F4 | Änderungen aus Git | Der Sollzustand liegt versioniert in Git (APP.4.4 A8). Im Test lässt sich eine Anwendung in Staging löschen und aus Git neu ausrollen. |
Reihenfolge der Prüfung
Beginnen Sie mit den Punkten, die einen Test mit Vorlauf brauchen: A1, A2, B4, D3, D4 und F2 (Ausfalltests, Lasttest, Restore, Wiederaufbau, Upgrade in Staging). Sie entscheiden, ob der Termin hält. Danach folgen die Punkte, die sich per Befehl oder Konfigurationsabgleich prüfen lassen: A3, A4, B1 bis B3, C1, C4, D1, D2 und E1 bis E5. Zuletzt kommen C2, C3, F1, F3 und F4. Alarme, Runbooks und Besetzung beruhen auf den Ergebnissen der ersten Gruppe.
Prüfbefehle
# A1: API-Server erreichbar, während ein Control-Plane-Node aus ist
kubectl get --raw='/readyz?verbose'
# A2: Node-Ausfall simulieren (Wartungsfenster oder Staging)
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl get pods -A --field-selector=status.phase=Pending
kubectl uncordon <node>
# A3: Deployments mit einer Replika, PodDisruptionBudgets
kubectl get deploy -A -o json | jq -r '.items[] | select(.spec.replicas==1) | .metadata.namespace + "/" + .metadata.name'
kubectl get pdb -A
# A4: Container ohne readinessProbe
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p | .spec.containers[] | select(.readinessProbe == null) | "\($ns)/\($p)/\(.name)"'
# B1: Container ohne Requests oder Memory-Limit
kubectl get pods -A -o json | jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $p | .spec.containers[] | select(.resources.limits.memory == null or .resources.requests.memory == null or .resources.requests.cpu == null) | "\($ns)/\($p)/\(.name)"'
# B2, B3: Quotas, Autoscaler, Reserve (Abschnitt "Allocated resources")
kubectl get resourcequota,limitrange,hpa -A
kubectl describe nodes
# B4: Pods mit OOMKilled
kubectl get pods -A -o json | jq -r '.items[] | select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled") | .metadata.namespace + "/" + .metadata.name'
# C1: Anzahl der Nodes mit dem Monitoring vergleichen
kubectl get nodes --no-headers | wc -l
# C4 (nur kubeadm, auf einem Control-Plane-Node), E5: Zertifikate und Version
kubeadm certs check-expiration
kubectl version
Welche Kubernetes-Version für das Go-live
Das Support-Ende steht auf kubernetes.io/releases. Für ein Go-live am 28.10.2026 ergibt sich:
| Version | Support-Ende | Monate bis zum Support-Ende | Regel E5 (mindestens 6 Monate) |
|---|---|---|---|
| 1.37 | 28.10.2027 | 12 | erfüllt |
| 1.36 | 28.06.2027 | 8 | erfüllt |
| 1.35 | 28.02.2027 | 4 | nicht erfüllt, Upgrade-Termin nötig |
| 1.34 | 27.10.2026 | beendet | nicht erfüllt |
Wann der Selbsttest nicht reicht
Der Selbsttest prüft, was das eigene Team messen kann. Er prüft nicht, ob die Kriterien zur Anwendung passen, und liefert keinen unabhängigen Bericht. Für Kundenfragebögen, Nachweise gegenüber Prüfern oder eine Zweitmeinung vor dem Go-live ist ein externes Konfigurations-Review gedacht. Es vergleicht den Cluster mit dem CIS Kubernetes Benchmark und APP.4.4 und ist kein Penetrationstest.
Unser Vorgehen bei WZ-IT
Das Cluster-Audit prüft Versionen und Upgrade-Pfad, RBAC und Service-Accounts, Secrets, Network Policies sowie Backup und Restore-Weg und gleicht den Cluster mit CIS und APP.4.4 ab. Ergebnis ist ein Bericht mit Befunden nach Priorität. Im Audit nehmen wir keine Änderungen am Cluster vor. Das Cluster-Audit kostet ab 1.490 € netto einmalig und wird auf den ersten Betriebsmonat angerechnet.
Den Betrieb nach dem Go-live übernimmt Managed Kubernetes ab 590 € netto je Cluster und Monat inklusive drei Worker-Nodes, mit Monitoring, Upgrades, Backups mit Restore-Test und Härtung. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Die Stufen stehen auf der SLA-Seite. Offene Punkte zu Upgrade, Zertifikaten oder etcd bearbeiten wir auch ohne Vertrag über den Kubernetes-Support, 120 € netto je Stunde, ohne zugesicherte Reaktionszeit. Preise netto, Stand Oktober 2026.
Stand und Methodik
- Stand: 28.10.2026. Die Support-Enden stammen von kubernetes.io/releases, abgerufen am 28.10.2026. Die Monate bis zum Support-Ende sind ab diesem Datum gezählt.
- Quellen der Kriterien: Kubernetes-Dokumentation (Production environment, Probes, PodDisruptionBudget, Ressourcenverwaltung, Security Checklist) und die BSI-Bausteine APP.4.4 und SYS.1.6, Edition 2023. Die Bausteine nennen Anforderungen wie Datensicherung im Cluster (APP.4.4 A5), Health Checks (A11) und Ressourcen-Limits (SYS.1.6.A15), aber für diese Punkte keine Zahlenwerte.
- Planungswerte: 70 % Request-Auslastung, Faktor 1,5 für den Lasttest, 30 Tage für Zertifikate, 6 Monate bis zum Support-Ende und 90 Tage für den Restore-Nachweis sind unsere Annahmen. Passen Sie sie an die Kritikalität an. Der Rhythmus von höchstens 90 Tagen folgt der vierteljährlichen Restore-Prüfung aus Kubernetes-Backup.
- Auswahl: Die 25 Punkte sind eine eigene Auswahl. Sie bilden die Bereiche ab, in denen Cluster beim Go-live und bei Übernahmen typischerweise Lücken haben, siehe die Übernahme-Checkliste.
- Abgrenzung: Selbsttest und Konfigurations-Review. Kein Penetrationstest.
Weiterführende Guides
- Kubernetes-Härtung: Checkliste - Bereich E vertieft, mit CIS, BSI und NIS2
- Kubernetes-Backup: die vier Ebenen - Bereich D im Detail
- Kubernetes-Cluster übernehmen: Audit-Checkliste - die Betriebssicht bei geerbten Clustern
- Longhorn vs. Rook-Ceph - welches Storage-System die Volumes trägt
Go-live mit externer Prüfung absichern? Das Cluster-Audit liefert den Bericht, Managed Kubernetes übernimmt den Betrieb danach. Cluster-Audit · Managed Kubernetes
Weiterführend: Kubernetes-Betriebskonzept nach APP.4.4
