Kubernetes Architektur Audit: Checkliste, Ablauf und Kosten

TL;DR

Ein Architektur-Audit prüft, ob der Cluster zur Last, zum Team und zu den Auflagen passt. Es ist kein Pentest. Geprüft werden Mandantentrennung, Netz, RBAC, Upgrade-Pfad, Backup und die Betriebsverantwortung. Für einen Produktions-Cluster im Mittelstand liegen externe Reviews typischerweise bei 3 bis 8 Personentagen, grob 4.000 bis 12.000 Euro (Schätzung, DACH, 2026, Konfidenz mittel). Wer nur Schwachstellen sucht, braucht einen Penetrationstest. Wer nur Rechte prüft, braucht ein RBAC-Audit.

Wann ein Architektur-Audit, wann nicht

Der Auslöser ist fast immer eine Entscheidung, keine Neugier:

• Ein Enterprise-Kunde fragt, wie Produktiv- und Kundendaten getrennt sind.
• NIS2, DORA oder ISO 27001 verlangen einen dokumentierten Stand, nicht nur einen Scan.
• Das Team will von einem einzelnen Cluster auf mehrere Umgebungen, und niemand kann sagen, welche Grenze wo liegt.
• Die Cloud-Rechnung oder die Incident-Rate zeigt, dass der Cluster gewachsen ist, das Betriebsmodell nicht.

Kein Audit brauchen Sie, wenn der Cluster ein Proof of Concept ohne Kundendaten ist. Dann reicht die Security-Checkliste. Ein Audit auf einem Wegwerf-Cluster erzeugt ein PDF, das in vier Wochen veraltet ist.

Was geprüft wird

Die sechs Angriffsflächen aus der Härtungs-Checkliste sind Teil davon, aber nicht das Ganze. Ein Cluster kann CIS-grün sein und trotzdem die falsche Tenancy haben.

Ablauf in fünf Phasen

1. Scope. Ein Cluster oder mehrere, welche Namespaces produktiv sind, ob die Control Plane beim Hyperscaler liegt. Ohne Scope wird aus dem Audit eine Cluster-Tour.
2. Soll. Welche Auflage gilt: interner Standard, Kundenvertrag, NIS2, DORA, ISO 27001. Das Soll bestimmt die Findings, nicht das Tool.
3. Ist. Read-only: kubectl api-resources, RBAC-Bindings, NetworkPolicies, Ingress, StorageClasses, Backup-Jobs. kube-bench und Trivy liefern die Baseline, ersetzen aber nicht die Frage, ob die Grenzen stimmen.
4. Bewertung. Jeder Befund mit Schwere, betroffener Grenze und konkreter Änderung. "RBAC verbessern" ist kein Finding. "ServiceAccount deploy in kube-system hat * auf * " ist eines.
5. Entscheid. Drei Ausgänge: härten und so lassen, Tenancy umbauen, oder Betrieb abgeben. Der dritte Ausgang ist der Vergleich Managed Service vs. selbst betreiben.

Produktive Änderungen gehören nicht in den Audit. Wer im Review schon NetworkPolicies ausrollt, vermischt Befund und Umsetzung und kann danach nicht mehr sagen, was der Kunde beauftragt hat.

12-Punkte-Checkliste

• Produktiv, Staging und Sandbox sind nicht derselbe Cluster ohne harte Grenze
• Kundendaten liegen nicht im Namespace neben CI-Workloads ohne NetworkPolicy
• Es gibt eine geschriebene Liste, wer cluster-admin hat, und sie ist kürzer als das Team
• ServiceAccounts haben keine Wildcard-Verbs auf Secrets
• Default-deny NetworkPolicy existiert in jedem Produktiv-Namespace
• Ingress ist die einzige geplante Nord-Süd-Tür, NodePorts sind begründet
• Images kommen aus einer Registry, die Sie kontrollieren, mit Digest oder festem Tag
• Admission blockt privilegierte Pods und HostPath, außer auf einer Ausnahmeliste
• etcd bzw. der gemanagte Control-Plane-Ersatz ist verschlüsselt, Backups liegen außerhalb des Clusters
• Ein Restore wurde in den letzten 90 Tagen geprobt, nicht nur ein Backup-Job
• Upgrade-Pfad der Minor-Version ist benannt, inklusive gesperrter APIs
• Ein Mensch ist on-call für die Plattform, nicht "das Entwicklerteam irgendwie"

Punkte 1, 6 und 10 fallen in Tool-Scans regelmäßig durch, weil sie Architektur sind und keine Fehlkonfiguration einer einzelnen Ressource.

Kostenrahmen

Das sind Marktbeobachtungen für den DACH-Raum 2026, keine Angebote. Ein Pentest liegt daneben, nicht darunter: andere Frage, anderer Bericht. Wer beides in einem Dokument will, zahlt die Summe, nicht den Rabatt.

Intern geht es günstiger und ist für den Kundenvertrag meist nicht unabhängig genug. Für die eigene Entscheidungsvorlage reicht intern, wenn jemand im Team die Grenzen benennen kann, ohne sie selbst gebaut zu haben.

Was Sie danach in der Hand haben

Einen Bericht mit Ist, Soll-Abweichung und einer Empfehlung: härten, umbauen oder abgeben. Dazu die Checkliste oben als Anhang, den ein Auditor lesen kann, ohne kubectl zu öffnen. Die technische Abarbeitung der Security-Punkte steht in der CIS-Benchmark-Härtung.

Wenn der Befund "kein Owner, kein Restore-Test, geteilte Tenancy" ist, ist mehr YAML die falsche Antwort. Dann ist die Frage, ob der Managed Service die Betriebsgrenze übernimmt.

FAQ

Ist ein Architektur-Audit ein Penetrationstest?

Nein. Der Pentest sucht ausnutzbare Lücken. Das Audit prüft, ob die Grenzen (Mandant, Netz, Verantwortung, Exit) zur Anforderung passen. Ein harter Cluster mit falscher Tenancy besteht den Pentest-Teil und fällt im Audit durch.

Reicht kube-bench?

Nein. kube-bench prüft den CIS-Benchmark, also Konfiguration gegen eine Liste. Es sagt nicht, ob drei Kunden in einem Cluster liegen dürfen. Die Liste ist die Baseline, nicht das Urteil.

Wie oft?

Einmal vor dem ersten Enterprise-Vertrag und danach bei jeder Grenzänderung: neuer Mandant, neuer Cluster, Wechsel des CNI oder des Providers. Ein jährlicher Pentest ersetzt das nicht.

Können wir das auf AKS, EKS oder GKE machen?

Ja. Die Control Plane gehört dem Anbieter und ist nur eingeschränkt sichtbar. Geprüft wird Ihre Ebene: Nodepools, RBAC, Netz, Workloads, Backup, Upgrade. Wer die Control Plane mitprüfen will, prüft den Vertrag, nicht kubectl.

Was ist der häufigste Fehlkauf nach dem Audit?

Ein Tool, das die Checkliste "automatisch" schließt. Polaris, Kyverno und Trivy finden Ressourcen. Sie entscheiden nicht, ob der Namespace die richtige Grenze ist. Die Entscheidung bleibt beim Team oder beim Betreiber.

Fazit

Ein Kubernetes-Architektur-Audit beantwortet eine Frage: Stimmen die Grenzen noch? Zwölf Prüfpunkte, fünf Phasen, ein Kostenrahmen von grob 4.000 bis 12.000 Euro für den typischen Mittelstands-Cluster. Danach gibt es drei saubere Ausgänge, nicht ein weiteres Dashboard.

Für eine erste Einordnung ohne Beauftragung: der Security Quick-Check. Für den Betrieb danach: Kontakt.