Cluster-Betrieb abgeben? WZ-IT betreibt Kubernetes auf Ihrer Infrastruktur oder gehostet in Deutschland: Updates, Datensicherung, Monitoring und Incident-Reaktion, mit Service Level je Cluster. Managed Kubernetes Betrieb
Ein Cluster läuft, solange nichts Ungeplantes passiert. Ein Betriebskonzept legt vorher fest, was bei Updates, Ausfällen, Personalwechsel und Prüfungen passiert. Der BSI-Baustein APP.4.4 Kubernetes stellt dazu fünf Basis-Anforderungen, die sich in einem Konzept bündeln lassen. Dieser Leitfaden liefert die Gliederung mit Mindestinhalt je Kapitel, eine RACI-Vorlage, die sechs Betriebsprozesse und die Dokumentationspflichten. Stand Oktober 2026.
Inhaltsverzeichnis
- Was APP.4.4 verlangt und was ein Betriebskonzept daraus macht
- Die fünf Basis-Anforderungen im Wortlaut
- Die Gliederung: elf Kapitel mit Mindestinhalt und Prüfkriterium
- Rollen und Verantwortungen: RACI-Vorlage
- Die sechs Betriebsprozesse
- Dokumentationspflichten
- Bei erhöhtem Schutzbedarf
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Was APP.4.4 verlangt und was ein Betriebskonzept daraus macht
Der Baustein APP.4.4 Kubernetes (Edition 2023) hat 21 Anforderungen. Er ist immer zusammen mit dem Baustein SYS.1.6 Containerisierung anzuwenden und nennt den IT-Betrieb als grundsätzlich zuständige Rolle. Ein Dokument namens Betriebskonzept schreibt er nicht vor. Er verlangt Planungen (A1, A2), geregelte Berechtigungen (A3) und eine Datensicherung (A5). Diese Inhalte gehören in ein Konzept, sonst bleiben sie in Köpfen und Tickets.
Zwei Dokumente haben unterschiedliche Aufgaben:
| Betriebskonzept | Betriebshandbuch | |
|---|---|---|
| Frage | Was gilt und wer entscheidet? | Wie wird es ausgeführt? |
| Inhalt | Architektur, Rollen, Regeln, Rhythmen, Ziele | Schritte, Befehle, Kontakte, Wiederherstellungsreihenfolge |
| Änderungsrate | selten, bei Entscheidungen | mit jeder Änderung am Cluster |
| Leser | Leitung, ISB, Fachverantwortliche, Betrieb | Betrieb, Bereitschaft, Vertretung |
Das Konzept verweist je Kapitel auf den Abschnitt des Handbuchs. Das Handbuch gehört wie die Konfiguration in die Versionsverwaltung (A8 sieht versionierte und annotierte Konfigurationsdateien als Standard-Anforderung vor).
Die fünf Basis-Anforderungen im Wortlaut
Die Basis-Anforderungen sind die mit MUSS formulierten Pflichten des Bausteins. Titel und Kernaussagen stehen hier in der Fassung des Bausteins.
| Nr. | Titel | Kernaussage im Wortlaut | Kapitel im Konzept |
|---|---|---|---|
| A1 | Planung der Separierung der Anwendungen | „Vor der Inbetriebnahme MUSS geplant werden“, wie Anwendungen und ihre Test- und Produktionsumgebungen separiert werden. „Die Planung MUSS Regelungen zu Netz-, CPU- und Festspeicherseparierung enthalten.“ | 1, 2 |
| A2 | Planung der Automatisierung mit CI/CD | Automatisierung mit CI/CD „DARF [...] NUR nach einer geeigneten Planung erfolgen“. Die Planung umfasst den „gesamten Lebenszyklus von Inbetrieb- bis Außerbetriebnahme“. „Das Rollen- und Rechtekonzept sowie die Absicherung von Kubernetes Secrets MÜSSEN Teil der Planung sein.“ | 5 |
| A3 | Identitäts- und Berechtigungsmanagement bei Kubernetes | Jede Aktion wird authentifiziert und autorisiert. „Administrative Handlungen DÜRFEN NICHT anonym erfolgen.“ Benutzende erhalten „NUR die unbedingt notwendigen Rechte“. | 3, 4 |
| A4 | Separierung von Pods | Der Kernel der Nodes isoliert Pods über Linux Namespaces und cgroups, mindestens „IDs von Prozessen sowie Benutzenden, Inter-Prozess-Kommunikation, Dateisystem und Netz inklusive Hostname“. | 2 |
| A5 | Datensicherung im Cluster | Gesichert werden Persistent Volumes, Konfigurationsdateien, Clusterzustand mit Erweiterungen, etcd, Infrastrukturanwendungen und die Datenhaltung der Registries. „Snapshots DÜRFEN die Datensicherung NICHT ersetzen.“ | 7, 10 |
A4 ist keine Planungsaufgabe. Das Konzept hält fest, auf welcher Runtime und welchen Nodes die Isolation beruht, und verweist auf den Prüfnachweis. Die Standard-Anforderungen A6 bis A12 ergänzen die Kapitel unten, zum Beispiel A7 (Netztrennung mit Whitelisting), A9 (Service-Accounts) und A11 (Health Checks).
Die Gliederung: elf Kapitel mit Mindestinhalt und Prüfkriterium
Die Tabelle ist die Vorlage. Jede Zeile ist ein Kapitel mit dem Mindestinhalt, den Anforderungen, auf die es sich stützt, und einem Prüfkriterium, das ein Dritter ohne Rückfrage nachprüfen kann. Bezüge auf andere Bausteine (CON.3, DER.2.1, OPS.1.1.3, OPS.1.1.5, SYS.1.6) sind Ergänzungen aus dem Kompendium, keine Bestandteile von APP.4.4.
| Nr. | Kapitel | Mindestinhalt | Bezug | Prüfkriterium |
|---|---|---|---|---|
| 1 | Geltungsbereich und Schutzbedarf | Cluster und Umgebungen (Test, Produktion), Liste der Anwendungen mit Schutzbedarf, Abgrenzung zu SYS.1.6 | A1 | Jede Anwendung hat Schutzbedarf und Umgebung. Kein Namespace ohne Zuordnung |
| 2 | Architektur und Separierung | Namespace-Schnitt (eine Anwendung, ein Namespace), welche Anwendungen einen Cluster teilen, Netzzonen, Regelungen zu Netz, CPU und Festspeicher, Isolation der Pods | A1, A4, A7 | Zu jeder Trennung steht eine Begründung. Abweichungen sind eingetragen |
| 3 | Rollen und Verantwortungen | RACI, Vertretung, Ansprechpersonen, Aufgabenteilung mit Dienstleister | A3, OPS.1.1.3.A2, DER.2.1.A3 | Jede Aufgabe hat genau eine verantwortliche Stelle. Kontaktdaten sind aktuell |
| 4 | Zugriffe und Berechtigungen | Authentifizierung für Menschen und Software, keine anonyme Administration, Mindestrechte, wer Volumes anlegen und das CNI verwalten darf, Service-Accounts | A3, A7, A9 | Der RBAC-Export enthält keine unbegründete cluster-admin-Bindung. Der Default-Service-Account hat keine Rechte |
| 5 | Änderungen und Automatisierung | Lebenszyklus der Pipeline, Secrets, Rechte der Pipeline, versionierte Konfiguration, Genehmigung, Rückfallweg | A2, A8, A10, OPS.1.1.3.A1 | Jede Änderung am Cluster lässt sich auf Commit und Freigabe zurückführen. Der Rückfallweg ist beschrieben |
| 6 | Updates und Patches | Versionsstrategie, Bewertung neuer Patches, Wartungsfenster, Umgang mit Versionen ohne Support | OPS.1.1.3.A15 | Alle Komponenten laufen in einer unterstützten Version. Jede Patch-Entscheidung ist dokumentiert |
| 7 | Datensicherung und Wiederherstellung | Die sechs Posten aus A5, Verfahren und Zeitpunkte, getrenntes Ziel, Aufbewahrung, Restore-Reihenfolge, Wiederherstellungsziele, Testrhythmus | A5, CON.3.A2, CON.3.A4, CON.3.A12, CON.3.A14, CON.3.A15 | Je kritischer Anwendung liegt ein Restore-Protokoll mit Datum und Dauer vor |
| 8 | Monitoring und Protokollierung | Health Checks, Alarmregeln, Schwellen, Zuständige, Aufbewahrung der Logs außerhalb der Container | A11, SYS.1.6.A7, OPS.1.1.5.A1 | Jeder Container hat readiness- und liveness-Check. Ein Testalarm erreicht die benannte Person |
| 9 | Incident-Management | Definition und Einstufung, Meldewege, Verantwortliche, Eindämmung, Wiederherstellung, Nachbereitung | DER.2.1.A1 bis A6, A9 bis A11, A17 | Ein Durchlauf (Übung) ist dokumentiert. Die Eskalationskontakte sind aktuell |
| 10 | Infrastrukturanwendungen | Registry, Storage (CSI), CNI, Pipeline, Konfigurationsablage: Zugang, Verschlüsselung, Berechtigungen, Protokollierung, Datensicherung | A12, A5 | Zu jeder Anwendung sind die fünf Punkte aus A12 beantwortet |
| 11 | Dokumentation und Prüfung | Dokumentenliste, Ablage, Verantwortliche, Review-Rhythmus, Anhang für erhöhten Schutzbedarf | A8, DER.2.1.A2 | Das Konzept trägt Stand-Datum und Freigabe. Der nächste Review hat einen Termin |
Die Kapitel 7 und 4 liefern die am leichtesten prüfbaren Nachweise: ein Restore-Protokoll und einen RBAC-Export. Die Nachweise dazu zeigt der Artikel Kubernetes NIS2 und ISO 27001: Nachweise im Cluster. Die Prüfkriterien der Sicherheitsebenen stehen in der Härtungs-Checkliste, die der Betriebsbereitschaft in der Go-Live-Checkliste.
Rollen und Verantwortungen: RACI-Vorlage
APP.4.4 nennt den IT-Betrieb als grundsätzlich zuständig. Der ISB sorgt dafür, dass die Anforderungen gemäß Sicherheitskonzept erfüllt und überprüft werden, und wird bei strategischen Entscheidungen einbezogen. Fachverantwortliche kommen aus CON.3 und OPS.1.1.3 hinzu: Sie definieren die Anforderungen ihrer Anwendungen an die Datensicherung (CON.3.A1) und sind für das Konzept zum Patch- und Änderungsmanagement vorrangig zuständig (OPS.1.1.3.A1). Die Tabelle verteilt diese Rollen auf Betriebsaufgaben. Sie ist ein Vorschlag von WZ-IT, kein Bestandteil des BSI-Kompendiums. R = führt aus, A = verantwortet (genau eine Stelle je Zeile), C = wird konsultiert, I = wird informiert.
| Aufgabe | Fachverantwortliche | ISB | IT-Betrieb | Entwicklungsteam |
|---|---|---|---|---|
| Schutzbedarf und Umgebungen festlegen (A1) | A/R | C | C | C |
| Architektur und Separierung planen (A1) | C | C | A/R | C |
| Rollen- und Rechtekonzept pflegen, Rechte prüfen (A3) | C | A | R | I |
| Pipeline und Release-Freigabe (A2, A10) | I | I | C | A/R |
| Änderungen genehmigen (OPS.1.1.3.A1) | C | C | A | R |
| Patches bewerten und einspielen (OPS.1.1.3.A15) | I | C | A/R | C |
| Datensicherung einrichten (A5, CON.3.A4) | C | C | A/R | C |
| Restore testen und protokollieren (CON.3.A15) | C | I | A/R | C |
| Health Checks der Anwendung definieren (A11) | I | I | C | A/R |
| Monitoring und Alarmierung betreiben (A11) | I | I | A/R | C |
| Sicherheitsvorfall behandeln (DER.2.1.A5) | I | C | A/R | C |
| Konzept pflegen und prüfen | C | A | R | C |
Bei einem Dienstleister übernimmt dieser die Ausführung (R) der Zeilen des IT-Betriebs. Welche Zeilen das sind, steht im Vertrag und im Kapitel 3; Als Vorschlag bleiben Schutzbedarf, Freigaben und Fachverantwortung beim Auftraggeber. Wie sich die Aufgaben zwischen Anbieter-Control-Plane, Dienstleister und Eigenbetrieb verteilen, zeigt Managed Kubernetes vs. Self-Hosted.
Die sechs Betriebsprozesse
Jeder Prozess wird im Konzept mit Ablauf, Nachweis und Prüfkriterium beschrieben. Die Ausführung im Detail gehört ins Betriebshandbuch.
Updates
- Neue Patch- und Minor-Versionen werden zeitnah bewertet. OPS.1.1.3.A15 verlangt die Bewertung und Priorisierung, die Entscheidung über das Einspielen und, wenn ein Patch nicht eingespielt wird, die dokumentierte Begründung.
- Die Versionsplanung folgt dem Supportzeitraum: Eine Minor-Version wird rund 14 Monate gepflegt, zwölf im Standard und zwei im Wartungsmodus (Patch Releases). Minor-Versionen werden nicht übersprungen (kubeadm-Upgrade). Der kubelet darf nicht neuer sein als der kube-apiserver (Version Skew Policy).
- Für Produkte ohne Herstellersupport ist zu prüfen, ob sie sicher betrieben werden können; andernfalls dürfen sie laut OPS.1.1.3.A15 nicht mehr verwendet werden.
Nachweis: Versionsstand je Komponente, Patch-Entscheidungen, Wartungsfenster. Prüfkriterium: keine Komponente außerhalb des Supports. Den Fahrplan im Detail beschreibt der Kubernetes-Upgrade-Leitfaden.
Datensicherung und Wiederherstellung
- Das Konzept zählt die sechs Posten aus A5 auf und ordnet jedem Verfahren, Zeitpunkt und Ziel zu.
- Datensicherungen liegen auf separaten Speichermedien (CON.3.A2), sind vor unbefugtem Zugriff und Überschreiben geschützt (CON.3.A14) und räumlich getrennt von den gesicherten Systemen (CON.3.A12).
- Der Restore wird regelmäßig getestet, vor allem ob Daten „einwandfrei und in angemessener Zeit“ zurückgespielt werden (CON.3.A15). Der Testrhythmus ist ein Vorschlag des Konzepts, zum Beispiel quartalsweise je kritischer Anwendung.
Nachweis: Sicherungsprotokolle, Restore-Protokoll mit Dauer. Prüfkriterium: Alle sechs Posten sind abgedeckt, ein Restore ist nicht älter als der festgelegte Rhythmus. Die vier Ebenen erklärt der Artikel Kubernetes-Backup; etcd-Snapshots beschreibt die Kubernetes-Dokumentation.
Monitoring
- Jeder Container definiert Health Checks für Start und Betrieb (A11). Auf Basis der Checks soll Kubernetes Pods löschen oder neu starten.
- Alarmregeln, Schwellen und Zuständige stehen im Konzept. Logs werden außerhalb der Container aufbewahrt, mindestens auf dem Container-Host (SYS.1.6.A7).
- Für den API-Server legt eine Audit-Policy fest, welche Ereignisse mit welchen Daten aufgezeichnet werden. Eine Richtlinie zur Protokollierung verlangt OPS.1.1.5.A1.
Prüfkriterium: Ein Testalarm erreicht innerhalb der vereinbarten Zeit die benannte Person.
Incident
- Das Konzept definiert, was ein Sicherheitsvorfall ist und wie er von Störungen im Tagesbetrieb abgegrenzt wird (DER.2.1.A1), und benennt Verantwortliche und Ansprechpersonen (DER.2.1.A3).
- Betroffene Stellen werden zeitnah informiert, Meldepflichten für Behörden und regulierte Branchen sind zu berücksichtigen (DER.2.1.A4).
- Bei der Wiederherstellung gilt: Daten aus Datensicherungen dürfen nur eingespielt werden, wenn sie vom Vorfall nicht betroffen waren, und Zugangsdaten betroffener Komponenten werden vorher geändert (DER.2.1.A6).
Prüfkriterium: Ein Durchlauf ist dokumentiert, die Kontaktliste ist aktuell.
Zugriffe
- Jede Aktion an Kubernetes und der Control Plane wird authentifiziert und autorisiert, auch die von Automatisierung (A3).
- Pods nutzen nicht den Default-Service-Account, jede Anwendung hat einen eigenen mit minimalen Rechten (A9). Nur ausgewählte Administrierende verwalten das CNI und legen Volumes an (A7, A3).
- Die Gruppe
system:mastersumgeht alle RBAC-Prüfungen und lässt sich nicht über Bindings entziehen (RBAC Good Practices); das Konzept regelt, wer darin Mitglied ist.
Nachweis: RBAC-Export mit Prüfvermerk. Prüfkriterium: Jede weitreichende Berechtigung hat Begründung und Inhaber.
Änderungen
- Änderungen an Komponenten, Software und Konfigurationsdaten folgen einem Konzept: geplant, genehmigt, dokumentiert, mit Rückfalllösung. Bei größeren Änderungen ist der ISB beteiligt (OPS.1.1.3.A1).
- Die Konfiguration des Clusters liegt versioniert und annotiert in der Verwaltungssoftware, Schreibrechte sind minimal (A8). Pipelines arbeiten mit den notwendigen Rechten, je Benutzergruppe mit eigenem Prozess (A10).
- Das angestrebte Sicherheitsniveau bleibt während und nach der Änderung erhalten (OPS.1.1.3.A1).
Prüfkriterium: Zu jeder Änderung der letzten Quartale gibt es Commit, Freigabe und Rückfallweg.
Dokumentationspflichten
Die Tabelle fasst zusammen, welche Dokumente das Konzept voraussetzt. Die Spalte „Aktualisierung“ ist ein Vorschlag.
| Dokument | Inhalt | Aktualisierung | Bezug |
|---|---|---|---|
| Betriebskonzept | Die elf Kapitel oben | jährlich und bei Änderung | A1, A2, A3 |
| Betriebshandbuch | Schritte, Kontakte, Wiederherstellungsreihenfolge | mit jeder Änderung am Cluster | CON.3.A4 |
| Konfiguration in Git | Sollzustand von Cluster, Erweiterungen, Anwendungen | laufend | A8 |
| Änderungsprotokoll | Anforderung, Genehmigung, Rückfall | je Änderung | OPS.1.1.3.A1 |
| Patch-Entscheidungen | Bewertung, Entscheidung, Begründung bei Verzicht | je Patch | OPS.1.1.3.A15 |
| Restore-Protokolle | Datum, Umfang, Dauer, Abweichungen | je Test | CON.3.A15 |
| Rechte-Export mit Prüfvermerk | Bindings, Gruppen, Service-Accounts | quartalsweise | A3, A9 |
| Incident-Protokolle | Ablauf, Maßnahmen, Nachbereitung | je Vorfall | DER.2.1 |
Bei erhöhtem Schutzbedarf
Die Anforderungen A13 bis A21 sind exemplarische Vorschläge, deren Festlegung aus einer Risikoanalyse folgt. Das Konzept führt sie als Anhang mit Entscheidung je Anforderung: umgesetzt, begründet verzichtet oder nicht zutreffend. Dazu zählen die automatisierte Auditierung gegen Benchmarks (A13), dedizierte Nodes (A14), eigene Cluster für Anwendungen mit sehr hohem Schutzbedarf (A15), Mikro-Segmentierung (A18), Hochverfügbarkeit über mehrere Brandabschnitte (A19) und verschlüsselte Datenhaltung der Dateisysteme einschließlich etcd (A20; für die API-Daten in etcd siehe ergänzend Verschlüsselung ruhender Daten).
Stand und Methodik
- Stand: 29.10.2026.
- Quellen der Anforderungen: APP.4.4 Kubernetes, Edition 2023, vollständig gelesen; Nummern, Titel und Zitate stammen aus dem Original-PDF. Aus CON.3, DER.2.1, OPS.1.1.3, OPS.1.1.5 und SYS.1.6 (jeweils Edition 2023) sind nur die genannten Anforderungen berücksichtigt.
- Eigene Zutaten: Gliederung, Prüfkriterien, RACI und Rhythmen sind Vorschläge von WZ-IT. Sie sind keine Vorgabe des BSI und kein offizielles Mapping.
- Kubernetes-Fakten: Dokumentation von kubernetes.io, abgerufen am 29.10.2026.
- Nicht enthalten: Rechtsauslegung, NIS2-Pflichten (siehe Nachweise im Cluster) und die Anforderungen anderer Bausteine, soweit oben nicht genannt.
Unser Vorgehen bei WZ-IT
- Bestand prüfen. Das Cluster-Audit gleicht den Cluster mit dem CIS Kubernetes Benchmark und APP.4.4 ab und liefert einen Bericht mit priorisierten Maßnahmen. Es ist ein Konfigurations-Review, kein Penetrationstest. Ab 1.490 Euro netto einmalig, anrechenbar auf den ersten Betriebsmonat.
- Aufgaben verteilen. Welche Zeilen der RACI-Tabelle WZ-IT übernimmt, legen Leistungsumfang und Service Level fest.
- Betreiben. Managed Kubernetes Betrieb übernimmt die Betriebsprozesse: Updates, Datensicherung, Monitoring und Incident-Reaktion. Der Betrieb kostet ab 590 Euro je Cluster und Monat inklusive 3 Worker-Nodes, netto. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level (Service Levels).
Weiterführende Guides
- Kubernetes-Härtung: Checkliste mit Prüfkriterien - Sicherheitsebenen nach CIS und APP.4.4
- Kubernetes Go-Live-Checkliste - 25 Prüfpunkte als Selbsttest
- Kubernetes-Backup: die vier Ebenen - Kapitel 7 im Detail
- Kubernetes NIS2 und ISO 27001: Nachweise - welche Belege der Cluster liefert
- Managed Kubernetes vs. Self-Hosted - Verantwortungsmatrix je Betriebsmodell
- Kubernetes-Cluster übernehmen: Audit-Checkliste - Bestand vor dem Betriebswechsel
Quellen
- BSI IT-Grundschutz-Kompendium: APP.4.4 Kubernetes, Edition 2023, abgerufen am 29.10.2026
- BSI: CON.3 Datensicherungskonzept, Edition 2023, abgerufen am 29.10.2026
- BSI: DER.2.1 Behandlung von Sicherheitsvorfällen, Edition 2023, abgerufen am 29.10.2026
- BSI: OPS.1.1.3 Patch- und Änderungsmanagement, Edition 2023, abgerufen am 29.10.2026
- BSI: OPS.1.1.5 Protokollierung, Edition 2023, abgerufen am 29.10.2026
- BSI: SYS.1.6 Containerisierung, Edition 2023, abgerufen am 29.10.2026
Cluster prüfen oder den Betrieb übergeben? Das Audit liefert den Bericht zur Cluster-Konfiguration, Managed Kubernetes setzt die Maßnahmen um. Cluster-Audit · Managed Kubernetes Betrieb
