Kubernetes nach BSI IT-Grundschutz: Der Baustein APP.4.4 in der Praxis

Wer als Behörde, KRITIS-Betreiber oder IT-Dienstleister der öffentlichen Hand Kubernetes betreibt, wird früher oder später am BSI IT-Grundschutz gemessen. Maßgeblich ist der Baustein APP.4.4 Kubernetes, für die Container selbst kommt SYS.1.6 Containerisierung hinzu.

APP.4.4 hat 21 Anforderungen: fünf Basis-Anforderungen, sieben Standard-Anforderungen und neun für erhöhten Schutzbedarf. Man kann sie als Checkliste für das nächste Audit lesen. Wir lesen sie lieber als Architekturvorgabe, weil sich die meisten Punkte nicht nachträglich an einen laufenden Cluster schrauben lassen.

Zum Stand: Das BSI stellt den IT-Grundschutz schrittweise auf Grundschutz++ um. Das Kompendium in der Edition 2023 gilt übergangsweise weiter. An den inhaltlichen Anforderungen an Kubernetes ändert sich dadurch wenig, die Umstellung sollte man trotzdem im Blick behalten.

Die Basis wird am Whiteboard entschieden

Die fünf Basis-Anforderungen sind im Kern Planungsaufgaben. A1 verlangt, vor der Inbetriebnahme festzulegen, wie Anwendungen und ihre Test- und Produktionsumgebungen voneinander getrennt werden, abhängig vom Schutzbedarf: über Namespaces, eigene Cluster oder eigene Netze. Diese Entscheidung bestimmt, wie viele Cluster Sie am Ende betreiben. Sie ist teuer, wenn man sie in Jahr zwei revidiert.

A2 betrifft die Automatisierung. Wer mit CI/CD ausrollt, muss den gesamten Lebenszyklus geplant haben, einschließlich Rollen- und Rechtekonzept und dem Umgang mit Kubernetes Secrets. A3 fordert, dass jede Aktion an der Control Plane authentifiziert und autorisiert wird, ob über kubectl, eine Weboberfläche oder die API, und dass niemand anonym administriert. In der Praxis heißt das: ein zentraler Identity Provider über OIDC und RBAC mit minimalen Rechten.

A4 verlangt Isolation der Pods durch den Kernel der Nodes, also Linux-Namespaces und cgroups. Das liefert jede aktuelle Container-Runtime, man sollte es nur nicht durch privilegierte Pods wieder aushebeln. A5 schließlich fordert eine Datensicherung des Clusters, ausdrücklich inklusive etcd, Persistent Volumes und Konfiguration. Snapshots allein reichen laut BSI nicht.

Netze: alles zu, dann gezielt öffnen

Die Standard-Anforderungen beschreiben im Wesentlichen, was ein ordentlich betriebener Cluster ohnehin tun sollte. Am häufigsten fehlt in unserer Erfahrung A7: Zwischen Namespaces soll zunächst jeder Netzverkehr untersagt und nur das Benötigte erlaubt sein.

Kubernetes erlaubt standardmäßig jeden Verkehr zwischen allen Pods. Eine Default-Deny-Policy pro Namespace dreht das um:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: fachverfahren-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Wer das zum ersten Mal ausrollt, stellt fest, dass danach auch DNS nicht mehr funktioniert. Das ist kein Fehler der Policy, sondern genau ihr Zweck. Die Ausnahme für DNS muss ausdrücklich erlaubt werden:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: fachverfahren-prod
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Network Policies wirken nur, wenn das eingesetzte CNI-Plugin sie durchsetzt. Das sollte man vor dem Audit prüfen, nicht währenddessen.

Service-Accounts und Pipelines

A9 verlangt, dass Pods nicht den default-Service-Account nutzen und jede Anwendung einen eigenen mit minimalen Rechten bekommt. Pods, die gar nicht mit der Kubernetes-API sprechen müssen, sollen den Token auch nicht sehen. Im Manifest ist das eine Zeile:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fachverfahren
  namespace: fachverfahren-prod
automountServiceAccountToken: false

A10 überträgt dasselbe Prinzip auf die Automatisierung: Pipelines arbeiten nur mit den Rechten, die sie brauchen. Eine CI/CD-Pipeline mit cluster-admin ist bequem, aber sie ist auch der attraktivste Angriffspunkt der ganzen Plattform.

Die übrigen Standard-Anforderungen sind schnell erklärt: Initialisierung in eigenen Init-Containern (A6), versionierte Konfigurationsdateien mit minimalen Zugriffsrechten (A8), Readiness- und Liveness-Checks für jeden Container (A11) und die Absicherung von Registry, Automatisierung und Storage-Verwaltung (A12).

Erhöhter Schutzbedarf bestimmt die Topologie

Bei erhöhtem Schutzbedarf kommen neun Anforderungen dazu, und einige davon verändern die Architektur grundlegend. A14 und A15 verlangen dedizierte Nodes und die Trennung von Anwendungen auf Node- oder Cluster-Ebene. A19 fordert Hochverfügbarkeit von Kubernetes selbst. Zusammen entscheiden sie über Anzahl, Größe und Verteilung Ihrer Cluster.

Andere Anforderungen sind eher Betriebsdisziplin. A13 verlangt automatisierte Audits der Konfiguration gegen standardisierte Benchmarks wie den CIS Kubernetes Benchmark, und der Cluster soll die Regeln selbst durchsetzen. A18 setzt die Netztrennung innerhalb eines Namespace fort (Mikro-Segmentierung), A20 verlangt die Verschlüsselung von etcd und persistenten Daten. A17 fordert die Attestierung von Nodes, möglichst per TPM, A16 Operatoren für kritische Betriebsaufgaben. Und A21 sieht vor, dass bei sehr hohem Schutzbedarf kein Pod länger als 24 Stunden läuft.

Warum wir das als Code umsetzen

Bei einem Cluster kann man APP.4.4 von Hand umsetzen. Bei zwanzig Clustern über drei Umgebungen funktioniert das nicht mehr, und bei einem Audit ist „wir haben das damals so eingerichtet“ kein Nachweis.

Wir beschreiben deshalb ein gehärtetes Cluster-Template einmal als Code: Network Policies, Rollen, Service-Accounts, Audit-Logging, Backup. Mit der Kubermatic Kubernetes Platform entsteht jeder neue Cluster aus dieser Vorlage, unabhängig vom Anbieter darunter. Regeln wie „kein default-Service-Account“ oder „jeder Container hat Health Checks“ prüft ein Policy-Werkzeug bei jedem Deployment im Cluster. Was dagegen verstößt, wird abgelehnt. Das deckt große Teile von A9, A11 und A13 ab, ohne dass jemand eine Checkliste abhaken muss.

Den Nachweis liefert dann das Repository: Jede Änderung an Infrastruktur und Konfiguration ist versioniert, begründet und von einer zweiten Person freigegeben.

---

APP.4.4 beschreibt im Grunde gute Kubernetes-Architektur. Wer Trennung, Identitäten, Automatisierung und Datensicherung im Entwurf festlegt und als Code umsetzt, erfüllt den Großteil der Anforderungen, bevor der Auditor kommt.