Security spielt die erste Geige Kubernetes 1.22 erfüllt die Anforderungen der Branche

„Kubernetes 1.22“ ist seit wenigen Wochen verfügbar. Grund genug, einen Blick auf die neueste Version der Open-Source-Container-Orchestrierung zu werfen. Wie reagiert sie auf die Herausforderungen des Datacenter-Multicloud-alles-sicher-Anspruchsdenkens?

Mitte des Jahres widmete sich der „Kubernetes and Cloud Native Operations Report“ genau diesem Thema. Für den Bericht wurden 1.200 IT-Profis und sieben Branchenexperten zu Cloud native befragt. Es ging im Einzelnen um Nutzungsgewohnheiten, Herausforderungen, Ziele und Wünsche der Anwender und Unternehmen bei dieser noch recht neuen Methode, Software zu entwickeln und bereitzustellen.

Diese Kubernetes-Version setzt ein klares Signal hin zu mehr Sicherheit. Drei der wichtigsten neuen Funktionen widmen sich der Sicherheit.

Ein kurzer Blick in den Bericht zeigt, dass dies den Bedürfnissen der Anwender entspricht. In erster Linie treibt sie die Sorge um die Sicherheit um: 46 Prozent sind der Meinung, dass die Sicherheit für DevOps-Entwickler, die mit nativen Cloud-Technologien arbeiten, ganz oben stehen sollte. Auch bei der Entwicklung von Containern beziehungsweise der Implementierung einer Edge-Strategie hat Security mit 56 beziehungsweise 49 Prozent die oberste Priorität.

Sicherheit von Kubernetes steht an erster Stelle

Diese neuen Kubernetes-Sicherheitsfunktionen sollten dem Wunsch der Entwickler entgegenkommen:

• 1. Cluster-weites seccomp-Profil: In Kubernetes 1.22 ist jetzt ein Cluster-weites seccomp-Profil standardmäßig enthalten. Seccomp hat im Linux-Kernel die Aufgabe, Prozesse an eine sehr begrenzte Anzahl von Systemaufrufen zu binden. Vor 1.22 erlaubte Kubernetes zwar bereits die Ausführung von Containern unter Verwendung eines seccomp-Profils. Die Funktion läuft immerhin schon seit Kubernetes 1.19 stabil, musste aber bisher optional über ein ‚Opt-in‘ aktiviert werden. Als Standardeinstellung kann die Funktion nunmehr verhindern, dass Hacker eine Vielzahl von bekannten Schwachstellen und Sicherheitsrisiken (CVEs) und Zero-Day-Schwachstellen ausnutzen.

• 2. Container im Rootless-Modus: Das Ausführen von Containern als Nicht-Root-Benutzer ist die wichtigste Best Practice für die Containersicherheit. Kubernetes 1.22 nutzt dieses Konzept in vollem Umfang genutzt, so dass die K8s-Steuerungsebene im Benutzerbereich ausgeführt werden kann.
  Insbesondere kann kubeadm nun bei Bedarf nicht als root betrieben werden, indem die Steuerungsebene mit niedrigeren Rechten ausgeführt wird. Die übrigen Komponenten des Kubernetes-Knotens können versuchsweise auch nicht als root arbeiten. Das macht es Angreifern bei einem kompromittierten Kubernetes-Cluster deutlich schwerer, die zugrunde liegende Infrastruktur zu attackieren.

• 3. PodSecurity-Zulassung zur Ersetzung von PodSecurityPolicy: Eine neue Funktion zum Zulassen von PodSecurity ist nun enthalten. Sie soll die seit Kubernetes 1.21 veraltete PodSecurityPolicy ersetzen. Der PodSecurity Admission Controller setzt Pod-Sicherheitsstandards auf der Ebene von Namensbereichen durch. Dem Bericht zufolge ist diese Methode der de facto-Weg zum Isolieren von Anwendungen in Kubernetes.

Der Admission Controller verfügt über drei Stufen zum Durchsetzen der Richtlinien:

• Enforce – Richtlinienverstöße führen zur Ablehnung des Pods.

• Audit – Richtlinienverstöße lösen einen Audit-Vermerk aus, sind aber ansonsten zulässig.

• Warn – Richtlinienverstöße lösen eine Warnung für den Benutzer aus, sind aber ansonsten zulässig.

Das Öffnen von Windows für neue Welten

Zahllose Unternehmen haben in der Vergangenheit Software für „Microsoft Windows“ entwickelt und betrieben. Das Betriebssystem hat zwar noch eine gewisse Wegstrecke vor sich, bevor es ein „erstklassiger Bewohner der Kubernetes-Plattform“ geworden ist. Kubernetes 1.22 kommt aber mit ein paar Verbesserungen und Erleichterungen für das Erstellen und Betreiben von Containern in großem Maßstab unter Windows daher.

So werden privilegierte Container, die bereits unter Linux verfügbar sind, nun auch unter Windows unterstützt. Sie haben direkten Host-Zugriff und sind für Verwaltungs-, Sicherheits- und Überwachungszwecke recht nützlich, auch wenn sie nicht für alle Workloads geeignet sind.

Im Rahmen der Neuerungen für Windows sind mit der Version 1.22 außerdem neue Entwickler-Tools veröffentlicht worden. Sie unterstützen verschiedenen CNI-Anbieter und sind auf mehreren Plattformen lauffähig. Über das manuelle Erstellen von Windows-Binärdateien für „Kubelet“ und „Kube-Proxy“ ermöglichen sie es auch, Early-Support Kubernetes-Funktionen unter Windows zu testen. Schließlich ist die CSI-Unterstützung für Windows, die zunächst als Alpha-Funktion in Kubernetes 1.16 veröffentlicht wurde, nun allgemein verfügbar.

Absichtsbezogene Konfiguration

Eine der von Canonical entwickelten Technologien, die auch Teil der CNCF-Landkarte ist, ist das Charmed Operator Framework. Dieses Cloud Native Landscape Project der Cloud Native Computing Foundation (CNCF) soll das bisher unerforschte Terrain der Cloud Native Technologien kartieren und die meisten Projekte und Produktangebote im Bereich der Cloud Native-Technologien zu kategorisieren.

Das Framework erlaubt es Benutzern vom Konfigurations-Management zum Anwendungs-Management überzugehen, indem sie die Geschäftsziele in einem Modell erfassen. Bei der Auswertung des Berichts zeigte es sich, dass die meisten Befragten, obwohl sie sich noch in einem frühen Stadium ihrer K8s-Reise befinden, Charmed Operators unbedingt ausprobieren wollten.

Es gibt noch viel zu tun, um das gesamte Management des Kubernetes-Lebenszyklus zu verbessern; die Einführung der Operator-Pattern ist dabei eine wichtige Etappe. Aktuell ergänzt Kubernetes mit Erweiterungen, die es den Benutzern ermöglichen, Cluster und Implementierungen intuitiver zu konfigurieren.

Auch der Schritt von Server-side Apply in den stabilen Modus in der Version 1.22 ist wichtig. Diese Funktion erlaubt es, Ressourcen über deklarative Konfigurationen zu verwalten. Änderungen an einer Ressource können Feld für Feld nachverfolgt werden, wobei ein fein abgestuftes Berechtigungsmodell implementiert wird.

Server-side Apply soll den Befehl kubectl apply ersetzen; der Mechanismus erleichtert es Benutzern und Controllern durch das Spezifizieren ihrer Absicht, Änderungen an ihren Konfigurationen vorzunehmen. Die neue Logik ist in den Kubernetes-API-Server implementiert, um die meisten Fallstricke von kubectl apply zu beheben und die Operationen direkt über die K8s-API zugänglich zu machen.

* Alex Chalkias ist Produktmanager für Datacenter bei Canonical.

(ID:47812584)