Kubernetes-Cluster übernehmen: Audit- und Übergabecheckliste

Ein Cluster erben oder den Betrieb abgeben? WZ-IT auditiert, stabilisiert und betreibt bestehende Kubernetes-Cluster mit eindeutigem Leistungsumfang - Monitoring, Updates, CVEs, Backup und Incident Response als ein Lifecycle. Managed Kubernetes ansehen

Ein Kubernetes-Cluster wechselt selten sauber den Besitzer. Ein Kollege geht, ein Dienstleister wird abgelöst, eine Übernahme bringt fremde Infrastruktur mit - und plötzlich verantwortet ein Team ein System, das es nicht gebaut hat. Bevor jemand Reaktionszeiten zusagt, braucht es eine ehrliche Bestandsaufnahme. Diese Checkliste ist der operative Audit-Rahmen dafür: nicht als Sicherheitsprüfung, sondern als Frage, ob das Cluster überhaupt verantwortbar betreibbar ist.

Inhaltsverzeichnis

• Warum jede Übernahme mit einem Audit beginnt
• Nicht zu verwechseln: Betriebs-Audit ist kein Security-Audit
• Die Übernahme-Checkliste
• Red Flags: woran Sie eine kritische Übernahme erkennen
• Vom Audit in den Betrieb

Warum jede Übernahme mit einem Audit beginnt

Ein geerbtes Cluster ist eine Blackbox, bis das Gegenteil bewiesen ist. Es kann undokumentierte Abhängigkeiten enthalten, längst abgekündigte Komponenten, manuell nachgezogene Konfiguration, die nirgends versioniert ist, und Recovery-Pfade, die noch nie durchgespielt wurden. Wer den Betrieb ohne Bestandsaufnahme zusagt, verspricht Verfügbarkeit für ein System, dessen Ausfallmodi er nicht kennt.

Das Audit dreht diese Reihenfolge um: erst Transparenz, dann Leistungsversprechen. Es beantwortet drei Fragen - Was läuft hier tatsächlich? Was ist das größte Risiko? Was muss stabilisiert werden, bevor ein SLA überhaupt sinnvoll ist? Erst danach werden Leistungsumfang, Verantwortlichkeiten und Reaktionszeiten vereinbart.

Nicht zu verwechseln: Betriebs-Audit ist kein Security-Audit

Ein Sicherheits-Audit prüft Härtung, Angriffsflächen, Pod Security, Netzwerkrichtlinien und Compliance. Das ist wichtig - aber es beantwortet nicht die Übernahme-Frage. Ein Cluster kann sauber gehärtet und trotzdem unbetreibbar sein, weil niemand die Zugänge vollständig kennt oder der Restore nie getestet wurde.

Das Übernahme-Audit fragt nach der Betreibbarkeit: Kenne ich alle Zugänge? Ist die Version noch im Support? Funktioniert die Wiederherstellung? Weiß ich, welche Anwendung von welcher Abhängigkeit lebt? Security ist eine Dimension davon, nicht der Zweck. Diese Unterscheidung ist auch der Grund, warum generische „Kubernetes-Audit-Checklisten" hier selten helfen: Sie behandeln fast immer Hardening, nicht Übergabe.

Die Übernahme-Checkliste

Neun Dimensionen, die vor jeder Betriebszusage geklärt sein müssen.

1. Zugänge und Inventar. Vollständige kubeconfig und Admin-Zugänge, Zugang zur darunterliegenden Infrastruktur (Proxmox, Provider-Konsole, Bare Metal), zu Registry, Git-Repositories, DNS und Zertifikatsverwaltung. Wichtig ist nicht nur, ob Zugang besteht, sondern ob er vollständig ist - ein fehlender Registry- oder DNS-Zugang blockiert später jeden Rollout.

2. Distribution, Version und Support-Skew. Welche Distribution (kubeadm, k3s, RKE2, Talos oder Managed)? Welche Kubernetes-Version - und liegt sie noch im Support-Fenster? Kubernetes pflegt nur etwa die drei jüngsten Minor-Linien. Ein Cluster mehrere Versionen dahinter erhält keine Sicherheits-Patches und lässt sich nur schrittweise, Minor für Minor, aktualisieren. Ebenso prüfen: Version der Node-Betriebssysteme und der Plattform-Add-ons.

3. Netzwerk: CNI, Ingress, Load Balancer, DNS. Welches CNI (Cilium, Calico, …) und welche Network Policies? Wie kommt Traffic herein - Ingress oder Gateway API, welcher Controller? Wer bei ingress-nginx steht, hat hier ein akutes Thema, weil das Community-Projekt eingestellt ist. Wie funktioniert Load Balancing (Provider-LB, MetalLB), und wie sind DNS und TLS automatisiert?

4. Storage, Backup und der Restore-Test. Welche StorageClasses und CSI-Treiber, wo liegen persistente Daten? Und dann die entscheidende Frage: Wurde ein vollständiger Restore je getestet? Ein belastbares Konzept sichert mehrere Ebenen getrennt - den etcd-Zustand der Control Plane, die versionierten Clusterdefinitionen, die persistenten Volumes und anwendungskonsistente Datenbank-Backups. Ein Snapshot allein ist keine dieser Ebenen vollständig.

5. Identität und RBAC. Wie authentifizieren sich Administratoren und Teams - statische Zugänge oder OIDC/SSO? Wer hat cluster-admin, und ist das nachvollziehbar? Ungenutzte, überberechtigte oder unpersönliche Zugänge sind ein häufiger Befund.

6. Observability. Gibt es Monitoring (Metriken), Logging und Alerting - und erzeugen die Alarme etwas Verwertbares oder nur Rauschen? Ohne Sichtbarkeit auf Control Plane, Nodes, Kernkomponenten und Kapazität lässt sich keine Reaktionszeit seriös zusagen.

7. Workloads und Abhängigkeiten. Welche Anwendungen laufen, welche sind geschäftskritisch, welche externen Abhängigkeiten (Datenbanken, APIs, Message-Broker) bestehen? Welche Deployment-Methode - GitOps, Helm, manuell? Ein Cluster, dessen Anwendungen manuell und undokumentiert ausgerollt wurden, birgt das größte Rekonstruktionsrisiko.

8. Lifecycle und Updates. Wie wurden bisher Kubernetes-Version, Betriebssysteme und Add-ons aktualisiert - geplant und getestet, oder gar nicht? Gibt es ein Wartungsfenster, gibt es Runbooks? Der Update-Rückstand ist oft der größte Einzelposten der Stabilisierung.

9. Verantwortungsgrenzen. Wer verantwortet nach der Übernahme welche Ebene - Control Plane, Nodes, Plattform-Add-ons, Workloads, Datenbanken, Anwendung? Ohne eine klare Shared-Responsibility-Zuordnung entstehen genau die Lücken, in denen ein Incident liegen bleibt.

Red Flags: woran Sie eine kritische Übernahme erkennen

Einzelne Befunde wiegen schwerer als andere. Diese fünf zeigen an, dass zuerst stabilisiert werden muss, bevor ein Betriebsumfang zugesagt werden kann:

• Kein getesteter Restore - Backups existieren, aber niemand hat je eine Wiederherstellung durchgespielt.
• Version außerhalb des Supports - mehrere Minor-Versionen hinter dem Support-Fenster, keine Sicherheits-Patches.
• Kein etcd-Backup oder unbekannt, wo und wie die Control Plane gesichert wird.
• Manuell ausgerollte, undokumentierte Workloads ohne versionierte Definition.
• Unklare oder geteilte Admin-Zugänge ohne nachvollziehbare Zuordnung.

Trifft mehreres davon zu, ist die ehrliche Antwort nicht „wir übernehmen ab morgen den 24/7-Betrieb", sondern „wir stabilisieren zuerst".

Vom Audit in den Betrieb

Aus dem Audit wird ein Übergang in klaren Phasen: Discovery und Risk-Baseline schaffen den akzeptierten Ist-Zustand, eine Stabilisierungsphase bringt Monitoring, Backups, Updates und Zugänge auf einen Mindeststandard, und erst die anschließende Service-Definition legt Umfang, Wartungsfenster, Reaktion und Verantwortlichkeiten fest. So wird aus einer geerbten Blackbox ein System mit vereinbartem Leistungsversprechen - statt einer Zusage ins Blaue.

Ob das Fundament überhaupt trägt, hängt oft von der darunterliegenden Infrastruktur ab; auf Proxmox und souveräner Infrastruktur lässt sich ein übernommenes Cluster sauber weiterbetreiben. Und ob ein Neuaufbau statt Übernahme sinnvoller ist, klärt Brauchen wir Kubernetes?