Kubernetes Sicherheit und Beobachtbarkeit

Kapitel 1. Strategie für Sicherheit und Beobachtbarkeit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Kapitel geben wir dir einen Überblick darüber, wie du eine Sicherheits- und Beobachtungsstrategie für deine Kubernetes-Implementierung entwickeln kannst. In den folgenden Kapiteln werden wir jedes dieser Konzepte ausführlicher behandeln. Du musst bereits in der Pilot-/Vorproduktionsphase deiner Kubernetes-Reise über eine Sicherheitsstrategie nachdenken. Wenn du also zum Sicherheitsteam gehörst, ist dieses Kapitel sehr wichtig. Wenn du zum Netzwerk-, Plattform- oder Anwendungsteam gehörst, zeigt dieses Kapitel, wie du ein Teil der Sicherheitsstrategie sein kannst und wie wichtig die Zusammenarbeit zwischen dem Sicherheits-, Plattform- und Anwendungsteam ist.

Wir werden die folgenden Konzepte behandeln, die dir bei deiner Sicherheits- und Beobachtungsstrategie helfen werden:

• Wie sich die Sicherung von Kubernetes von traditionellen Sicherheitsmethoden unterscheidet

• Der Lebenszyklus der Bereitstellung von Anwendungen (Workloads) in einem Kubernetes-Cluster und bewährte Methoden für jede Phase

• Wie du Beobachtbarkeit implementieren solltest, um die Sicherheit zu erhöhen

• Bekannte Sicherheits-Frameworks und wie du sie in deiner Sicherheitsstrategie einsetzen kannst

Sicherheit für Kubernetes: Eine neue und andere Welt

In diesem Abschnitt werden wir aufzeigen, wie sich Kubernetes unterscheidet und warum traditionelle Sicherheitsmethoden in einer Kubernetes-Implementierung nicht funktionieren.

Mit der Verlagerung von Workloads in die Cloud ist Kubernetes der gängigste Orchestrator für deren Verwaltung. Der Grund, warum Kubernetes so beliebt ist, ist seine deklarative Natur: Es abstrahiert die Details der Infrastruktur und ermöglicht es den Nutzern, die Arbeitslasten, die sie ausführen wollen, und die gewünschten Ergebnisse zu spezifizieren. Das Anwendungsteam muss sich nicht darum kümmern, wie und wo die Workloads ausgeführt werden, oder um andere Details wie die Vernetzung; es muss lediglich Konfigurationen in Kubernetes einrichten, um seine Anwendungen bereitzustellen.

Kubernetes erreicht diese Abstraktion, indem es die Erstellung, das Herunterfahren und den Neustart von Workloads verwaltet. In einer typischen Implementierung kann ein Workload auf jeder verfügbaren Ressource in einem Netzwerk (physischer Host oder virtuelle Maschine) entsprechend den Anforderungen des Workloads geplant werden. Eine Gruppe von Ressourcen, auf denen ein Workload ausgeführt wird, wird als Kubernetes-Cluster bezeichnet. Kubernetes überwacht den Status von Workloads (die in Kubernetes als Pods bereitgestellt werden) und ergreift bei Bedarf Korrekturmaßnahmen (z. B. Neustart von nicht reagierenden Knoten). Außerdem verwaltet sie alle Netzwerke, die Pods und Hosts benötigen, um miteinander zu kommunizieren. Du hast die Möglichkeit, die Netzwerktechnologie selbst zu bestimmen, indem du aus einer Reihe von unterstützten Netzwerk-Plug-ins auswählst. Es gibt zwar einige Konfigurationsoptionen für das Netzwerk-Plug-in, aber du kannst das Netzwerkverhalten nicht direkt steuern (weder bei der Zuweisung von IP-Adressen noch in typischen Konfigurationen, bei denen der Knoten zeitlich geplant ist).

Kubernetes ist eine andere Welt für Sicherheitsteams. Die herkömmliche Methode besteht darin, ein "Netzwerk von Maschinen" aufzubauen und dann die Workloads (Anwendungen) einzubinden. Im Rahmen des Onboardings wurden IPs zugewiesen, das Netzwerk nach Bedarf aktualisiert und Regeln für die Zugriffskontrolle im Netzwerk definiert und implementiert. Nach diesen Schritten war die Anwendung für die Benutzer bereit. Dieser Prozess stellte sicher, dass die Sicherheitsteams viel Kontrolle hatten und die Anwendungen problemlos einführen und sichern konnten. Die Anwendungen waren leicht zu sichern, da die Anwendungen in Bezug auf die zugewiesenen IPs, den Einsatzort usw. statisch waren.

In der Kubernetes-Welt werden Workloads als Container-Images erstellt und mithilfe einer Konfigurationsdatei (yaml) in einem Kubernetes-Cluster bereitgestellt. Dies ist in der Regel in den Entwicklungsprozess integriert, und die meisten Entwicklungsteams nutzen Continuous Integration (CI) und Continuous Delivery (CD), um eine schnelle und zuverlässige Bereitstellung von Software zu gewährleisten. Das bedeutet, dass das Sicherheitsteam nur einen begrenzten Einblick in die Auswirkungen der einzelnen Anwendungsänderungen auf die Sicherheit des Clusters hat. Es ist kontraproduktiv, diesen Prozess um einen Schritt der Sicherheitsüberprüfung zu erweitern, denn der einzige logische Ort dafür ist der Zeitpunkt, an dem der Code übergeben wird. Der Entwicklungsprozess ist ab diesem Zeitpunkt automatisiert und eine Unterbrechung würde dem CI/CD-Modell widersprechen. Wie kannst du also Workloads in dieser Umgebung sichern?

Um zu verstehen, wie man Workloads in Kubernetes sichert, ist es wichtig, die verschiedenen Phasen zu verstehen, die zur Bereitstellung eines Workloads gehören.

Bereitstellen eines Workloads in Kubernetes: Sicherheit in jeder Phase

Im vorherigen Abschnitt haben wir die Herausforderung beschrieben, Anwendungen zu sichern, die über die CI/CD-Pipeline bereitgestellt werden. In diesem Abschnitt wird der Lebenszyklus der Workload-Bereitstellung in einem Kubernetes-Cluster beschrieben und erläutert, wie die einzelnen Phasen gesichert werden können. Die drei Phasen der Workload-Bereitstellung sind die Build-, Deploy- und Runtime-Phase. Im Gegensatz zu traditionellen Client-Server-Anwendungen, bei denen eine Anwendung auf einem Server (oder einem Cluster von Servern) existiert, sind die Anwendungen in einem Kubernetes-Einsatz verteilt und das Netzwerk des Kubernetes-Clusters wird von den Anwendungen als Teil des normalen Betriebs genutzt. Hier sind einige Dinge, die du bei dieser Konfiguration beachten solltest:

• Du musst bewährte Methoden für die Sicherheit berücksichtigen, wenn du Workloads und Infrastruktur aufbaust. Dies ist wichtig, da Anwendungen in Kubernetes über die CI/CD-Pipeline bereitgestellt werden.

• Bei der Bereitstellung eines Kubernetes-Clusters und dem Onboarding von Anwendungen musst du bewährte Methoden für die Sicherheit berücksichtigen.

• Schließlich nutzen die Anwendungen die Infrastruktur und das Netzwerk des Kubernetes-Clusters für den normalen Betrieb, und du musst bewährte Methoden für die Sicherheit der Anwendungslaufzeit berücksichtigen.

Abbildung 1-1 veranschaulicht die verschiedenen Phasen und Aspekte, die bei der Sicherung von Workloads in einer Kubernetes-Umgebung zu berücksichtigen sind.

Abbildung 1-1. Stufen der Workload-Einführung und Sicherheit in jeder Stufe

In den Kästen unter jeder Phase werden verschiedene Sicherheitsaspekte beschrieben, die du für die jeweilige Phase berücksichtigen musst:

• In der Build-Phase erstellst du die Software für deinen Workload (Anwendung) und baust die Infrastrukturkomponenten (Host oder virtuelle Maschinen), um die Anwendungen zu hosten. Diese Phase ist Teil des Entwicklungszyklus, und in den meisten Fällen ist das Entwicklungsteam dafür verantwortlich. In dieser Phase berücksichtigst du die Sicherheit für die CI/CD-Pipeline, implementierst Sicherheit für Image-Repositories, scannst Images auf Schwachstellen und härtest das Host-Betriebssystem. Du musst sicherstellen, dass du bewährte Methoden zur Sicherung der Image-Registry implementierst und eine Gefährdung der Images in der Image-Registry vermeidest. Dies geschieht in der Regel durch die Sicherung des Zugriffs auf die Bildregistrierung, obwohl viele Nutzer/innen private Registrierungen haben und keine Bilder aus öffentlichen Registrierungen zulassen. Schließlich musst du bewährte Methoden für die Verwaltung von Geheimnissen berücksichtigen; Geheimnisse sind wie Passwörter, die den Zugriff auf Ressourcen in deinem Cluster ermöglichen. Wir werden diese Themen in Kapitel 3 ausführlich behandeln. Wir empfehlen, dass du bei deinen Überlegungen zur Sicherheit in dieser Phase mit dem Sicherheitsteam zusammenarbeitest, damit die Sicherheit in dieser Phase mit deiner allgemeinen Sicherheitsstrategie in Einklang gebracht wird.

• In der nächsten Phase, dem Deployment, richtest du die Plattform ein, auf der deine Kubernetes-Bereitstellung ausführt und Arbeitslasten bereitstellt. In dieser Phase musst du dir Gedanken über die bewährten Methoden für die Sicherheit bei der Konfiguration deines Kubernetes-Clusters und den externen Zugriff auf Anwendungen machen, die innerhalb deines Kubernetes-Clusters laufen. Außerdem musst du Sicherheitskontrollen in Betracht ziehen, z. B. Richtlinien zur Beschränkung des Zugriffs auf Workloads (Pod-Sicherheitsrichtlinien), Netzwerkrichtlinien zur Kontrolle des Zugriffs von Anwendungen auf die Plattformkomponenten und rollenbasierte Zugriffskontrollen (RBAC) für den Zugriff auf Ressourcen (z. B. für die Erstellung von Diensten und Namensräumen sowie das Hinzufügen/Ändern von Labels für Pods). In den meisten Unternehmen ist das Plattformteam für diese Phase verantwortlich. Als Mitglied des Plattformteams musst du sowohl mit dem Entwicklungs- als auch mit dem Sicherheitsteam zusammenarbeiten, um deine Sicherheitsstrategie umzusetzen.

• Die letzte Phase ist die Laufzeitphase, in der du deine Anwendung implementiert hast und sie betriebsbereit ist. In dieser Phase musst du über die Netzwerksicherheit nachdenken. Dazu gehören Kontrollen mit Hilfe von Netzwerkrichtlinien, Bedrohungsabwehr (Techniken zur Erkennung und Verhinderung bösartiger Aktivitäten im Cluster) und Sicherheitskontrollen im Unternehmen wie Compliance, Auditing und Verschlüsselung. Das Sicherheitsteam ist für diese Phase der Einführung verantwortlich. Als Mitglied des Sicherheitsteams musst du mit dem Plattform- und dem Entwicklungsteam zusammenarbeiten, wenn du die Laufzeitsicherheit konzipierst und implementierst. Die Zusammenarbeit zwischen den Teams (Entwicklung, Plattform und Sicherheit) ist sehr wichtig, um eine effektive Sicherheitsstrategie zu entwickeln. Wir empfehlen, dass du sicherstellst, dass alle diese Teams aufeinander abgestimmt sind.

Im Gegensatz zu traditionellen Sicherheitsstrategien, bei denen die Sicherheit an einem bestimmten Punkt (z. B. dem Perimeter) durchgesetzt wird, musst du im Falle eines Kubernetes-Clusters die Sicherheit in jeder Phase implementieren. Außerdem spielen alle beteiligten Teams (Anwendung, Plattform und Sicherheit) eine wichtige Rolle bei der Umsetzung der Sicherheit, sodass der Schlüssel zur Umsetzung einer erfolgreichen Strategie in der Zusammenarbeit zwischen den Teams liegt. Erinnere dich: Sicherheit ist eine gemeinsame Aufgabe. Sehen wir uns die einzelnen Phasen und die Techniken an, mit denen du deine Strategie aufbauen kannst.

Build-Time Security: Nach links schieben

Dieser Abschnitt führt dich anhand von Beispielen durch verschiedene Aspekte der Build-Time-Sicherheit .

Bild scannen

In dieser Phase musst du sicherstellen, dass die Anwendungen keine größeren ungepatchten Schwachstellen aufweisen, die in der National Vulnerability Database als CVEs (Common Vulnerability Enumerations) offengelegt sind, und dass der Anwendungscode und die Abhängigkeiten auf Exploits und verwundbare Codesegmente gescannt werden. Die Images, die als Container erstellt und ausgeliefert werden, werden dann auf ungepatchte kritische oder schwerwiegende Schwachstellen gescannt, die als CVEs bekannt sind. Dazu werden in der Regel das Basisbild und alle darin enthaltenen Pakete mit einer Datenbank abgeglichen, in der verwundbare Pakete verzeichnet sind. Für das Scannen gibt es verschiedene Tools, sowohl Open Source als auch kommerzielle, die dir zur Verfügung stehen. Whitesource, Snyk, Trivy, Anchor und sogar Cloud-Provider wie Google bieten Scans von Container-Images an. Wir empfehlen dir, eine Scan-Lösung zu wählen, die versteht, wie Container aufgebaut sind, und nicht nur das Betriebssystem auf dem Host, sondern auch die Basisbilder für Container scannt. Angesichts des dynamischen Charakters von Kubernetes-Einsätzen ist es sehr wichtig, dass du die CI/CD-Pipeline absicherst; das Scannen von Code und Images muss Teil der Pipeline sein, und Images, die von der Image-Registry geliefert werden, müssen auf Kompromisse überprüft werden. Du musst sicherstellen, dass der Zugriff auf die Registry kontrolliert wird, um Kompromisse zu vermeiden. Der gängige Begriff für diese Phase ist " Verlagerung der Sicherheit nach links zum Entwicklungsteam", auch bekannt als "shift-left security".

Härtung des Host-Betriebssystems

Hier musst du sicherstellen, dass die Anwendung, die du bereitstellst, nur die erforderlichen Berechtigungen auf dem Host hat, auf dem sie bereitgestellt wird. Um dies zu erreichen, solltest du ein gehärtetes Host-Betriebssystem verwenden, das Kontrollen unterstützt, die es ermöglichen, Anwendungen auf die notwendigen Rechte wie Systemaufrufe und Dateisystemzugriff zu beschränken. Auf diese Weise kannst du Angriffe durch Privilegienerweiterung, bei denen eine Schwachstelle in der Software in einem Container ausgenutzt wird, um Zugriff auf das Host-Betriebssystem zu erhalten, wirksam abwehren.

Minimierung der Angriffsfläche: Basisbilder für Container-Images

Wir empfehlen dir, die Zusammensetzung des Container-Images zu überprüfen und die Softwarepakete, aus denen das Basisbild besteht, so zu minimieren, dass nur Pakete enthalten sind, die für die Ausführung deiner Anwendung unbedingt erforderlich sind. Bei Dockerfile-basierten Container-Images kannst du mit einem Basisbild beginnen und dann deine Anwendung zu diesem Bild hinzufügen, um ein Container-Image zu erstellen. Du kannst zum Beispiel damit beginnen, ein Basisbild in Docker zu erstellen, indem du die Direktive FROM scratch verwendest, die ein minimales Bild erzeugt. Dann kannst du deine Anwendung und die benötigten Pakete hinzufügen. So hast du die vollständige Kontrolle über die Zusammensetzung deiner Container-Images und kannst auch die CVE-Verwaltung vereinfachen, da du dich nicht um das Patchen von CVEs in Paketen in einem Container-Image kümmern musst, die von deiner Anwendung nicht benötigt werden. Falls die Erstellung eines Scratch-Images nicht in Frage kommt, kannst du auch mit einem distroless-Image (einem abgespeckten Linux-Distributions-Image) oder einem Alpine-Minimal-Image als Basisbild für deinen Container beginnen.

Diese Techniken werden dir helfen, deine Sicherheitsstrategie für die Build-Time zu entwerfen und umzusetzen. Als Teil des Entwicklungsteams bist du dafür verantwortlich, die Build-Time-Sicherheit in Zusammenarbeit mit den Plattform- und Sicherheitsteams zu entwerfen und umzusetzen, um sicherzustellen, dass sie mit der allgemeinen Sicherheitsstrategie übereinstimmt. Wir warnen davor, dem Mythos Glauben zu schenken, dass Shift-Links-Sicherheit deine gesamte Sicherheitsstrategie sein kann. Das ist falsch und ein naiver Ansatz zur Sicherung von Workloads. Es gibt noch andere wichtige Aspekte, wie z. B. die Sicherheit bei der Bereitstellung und während der Laufzeit, die ebenfalls als Teil der Sicherheitsstrategie berücksichtigt werden müssen.

Sicherheit während des Einsatzes

Der nächste Schritt zur Sicherung von Workloads ist die Sicherung der Bereitstellung. Dazu musst du deinen Kubernetes-Cluster, in dem die Arbeitslasten bereitgestellt werden, absichern. Du musst die Konfiguration des Kubernetes-Clusters genau überprüfen, um sicherzustellen, dass sie den bewährten Methoden für die Sicherheit entspricht. Beginne damit, ein Vertrauensmodell für die verschiedenen Komponenten deines Clusters zu erstellen. Ein Vertrauensmodell ist ein Rahmen, in dem du ein Bedrohungsprofil überprüfst und Mechanismen definierst, um darauf zu reagieren. Du solltest Tools wie rollenbasierte Zugriffskontrolle (RBAC), Label-Taxonomien, Label-Governance und Zugangskontrollen nutzen, um das Vertrauensmodell zu entwerfen und umzusetzen. Dabei handelt es sich um Mechanismen zur Kontrolle des Zugriffs auf Ressourcen sowie um Kontrollen und Validierungen, die bei der Erstellung von Ressourcen angewendet werden. Diese Themen werden in den Kapiteln 3, 4 und7 ausführlich behandelt. Die anderen kritischen Komponenten deines Clusters sind der Kubernetes-Datenspeicher und der Kubernetes-API-Server. Wenn du das Vertrauensmodell für diese Komponenten entwirfst, musst du auf Details wie Zugriffskontrolle und Datensicherheit achten. Wir empfehlen dir, starke Anmeldeinformationen, eine Public Key Infrastructure (PKI) für den Zugang und Transport Layer Security (TLS) für die Verschlüsselung der Daten während der Übertragung zu verwenden. Die Absicherung der Kubernetes APT und des Datenspeichers wird in Kapitel 2 ausführlich behandelt.

Du solltest den Kubernetes-Cluster, in dem geschäftskritische Workloads eingesetzt werden, als eine Einheit betrachten und dann ein Vertrauensmodell für diese Einheit entwerfen. Dazu musst du die Sicherheitskontrollen am Perimeter überprüfen, was aufgrund der Kubernetes-Bereitstellungsarchitekturen eine Herausforderung darstellt; wir werden dies im nächsten Abschnitt behandeln. Nehmen wir an, dass die aktuellen Produkte, die am Perimeter eingesetzt werden, wie z. B. Web-Zugriffskontroll-Gateways und Firewalls der nächsten Generation, die Architektur von Kubernetes nicht kennen. Wir empfehlen dir, dieses Problem zu lösen, indem du Integrationen mit diesen Geräten erstellst, die ihnen den Kontext des Kubernetes-Clusters bekannt machen, damit sie die Sicherheitskontrollen am Perimeter effektiv anwenden können. Auf diese Weise kannst du eine sehr effektive Sicherheitsstrategie entwickeln, bei der die Perimeter-Sicherheitsgeräte mit den Sicherheitsmaßnahmen innerhalb deines Kubernetes-Clusters zusammenarbeiten. Angenommen, du möchtest, dass diese Geräte die Identität deiner Workloads kennen (IP-Adresse, TCP/UDP-Port usw.). Diese Geräte können die Hosts, aus denen dein Kubernetes-Cluster besteht, wirksam schützen, aber in den meisten Fällen können sie nicht zwischen den Arbeitslasten unterscheiden, die auf einem einzelnen Host laufen. Wenn du in einer Cloud-Provider-Umgebung arbeitest, kannst du Sicherheitsgruppen verwenden. Dabei handelt es sich um virtuelle Firewalls, die die Zugriffskontrolle auf eine Gruppe von Knoten (z. B. EC2-Instanzen in Amazon Web Services) ermöglichen, auf denen Workloads laufen. Sicherheitsgruppen sind besser auf die Kubernetes-Architektur abgestimmt als herkömmliche Firewalls und Sicherheitsgateways. Allerdings kennen auch Sicherheitsgruppen nicht den Kontext der Arbeitslasten, die innerhalb des Clusters laufen.

Zusammenfassend lässt sich sagen, dass du ein Vertrauensmodell für deinen Kubernetes-Cluster implementieren und eine effektive Integration mit Perimeter-Sicherheitsgeräten zum Schutz deines Clusters aufbauen musst, wenn du über die Sicherheit bei der Bereitstellung nachdenkst.

Laufzeitsicherheit

Nachdem du nun eine Strategie zur Sicherung der Build- und Deployment-Phasen hast, musst du dir Gedanken über die Laufzeitsicherheit machen. Der Begriff Laufzeitsicherheit wird für verschiedene Aspekte der Absicherung eines Kubernetes-Clusters verwendet, z. B. auf einem Host, auf dem Software läuft. Aber auch jede Konfiguration, die den Host und die Workloads vor unbefugten Aktivitäten schützt (z. B. Systemaufrufe, Dateizugriff), wird als Laufzeitsicherheit bezeichnet. Kapitel 4 befasst sich ausführlich mit der Host- und Workload-Laufzeitsicherheit. In diesem Abschnitt konzentrieren wir uns auf die bewährten Methoden, die für den sicheren Betrieb des Kubernetes-Cluster-Netzwerks erforderlich sind. Kubernetes ist ein Orchestrator, der Workloads und Anwendungen in einem Netzwerk von Hosts bereitstellt. Die Netzwerksicherheit ist ein sehr wichtiger Aspekt der Laufzeitsicherheit.

Kubernetes verspricht eine höhere Agilität und eine effizientere Nutzung der Rechenressourcen im Vergleich zur statischen Partitionierung und Bereitstellung von Servern oder VMs. Dies geschieht durch die dynamische Planung von Arbeitslasten im gesamten Cluster unter Berücksichtigung der Ressourcennutzung auf jedem Knoten und die Verbindung von Arbeitslasten über ein flaches Netzwerk. Wenn eine neue Arbeitslast bereitgestellt wird, kann der entsprechende Pod standardmäßig auf einem beliebigen Knoten im Cluster mit einer beliebigen IP-Adresse innerhalb der Pod-IP-Adresse eingeplant werden. Wenn der Pod später woanders eingeplant wird, erhält er normalerweise eine andere IP-Adresse. Das bedeutet, dass IP-Adressen von Pods als flüchtig zu betrachten sind. Die IP-Adressen der Pods oder ihr Standort im Netzwerk haben keine langfristige oder besondere Bedeutung.

Betrachten wir nun die traditionellen Ansätze zur Netzwerksicherheit. In der Vergangenheit wurde die Netzwerksicherheit in Unternehmensnetzwerken mit Sicherheits-Appliances (oder virtuellen Versionen von Appliances) wie Firewalls und Routern umgesetzt. Die Regeln, die von diesen Appliances durchgesetzt wurden, basierten oft auf einer Kombination aus der physischen Topologie des Netzwerks und der Zuweisung bestimmter IP-Adressbereiche an verschiedene Klassen von Arbeitslasten.

Da Kubernetes auf einem flachen Netzwerk ohne besondere Bedeutung für die IP-Adressen der Pods basiert, sind nur sehr wenige dieser traditionellen Appliances in der Lage, eine sinnvolle Workload-bezogene Netzwerksicherheit zu bieten und müssen stattdessen den gesamten Cluster als eine Einheit behandeln. Hinzu kommt, dass der Ost-West-Verkehr zwischen zwei Pods, die auf demselben Knoten gehostet werden, nicht einmal über das zugrunde liegende Netzwerk läuft. Diese Appliances sehen diesen Datenverkehr also überhaupt nicht und sind im Wesentlichen auf die Nord-Süd-Sicherheit beschränkt, die den Datenverkehr, der von externen Quellen in den Cluster gelangt, und den Datenverkehr, der von innerhalb des Clusters zu Quellen außerhalb des Clusters geht, schützt.

Angesichts all dessen sollte klar sein, dass Kubernetes einen neuen Ansatz für die Netzwerksicherheit erfordert. Dieser neue Ansatz muss ein breites Spektrum an Überlegungen abdecken, darunter:

• Neue Wege zur Durchsetzung der Netzwerksicherheit (welche Workloads dürfen mit welchen anderen Workloads kommunizieren), die nicht auf speziellen Bedeutungen von IP-Adressen oder der Netzwerktopologie beruhen und auch dann funktionieren, wenn der Datenverkehr nicht das zugrunde liegende Netzwerk durchquert; die Kubernetes-Netzwerkrichtlinie ist darauf ausgelegt, diese Anforderungen zu erfüllen.

• Neue Tools zur Verwaltung von Netzwerkrichtlinien, die neue Entwicklungsprozesse und den Wunsch nach Microservices unterstützen, um die organisatorische Flexibilität zu erhöhen, wie z. B. Richtlinienempfehlungen, Vorschauen auf die Auswirkungen von Richtlinien und Policy Staging.

• Neue Möglichkeiten, den Netzwerkverkehr zu überwachen und zu visualisieren. Dabei geht es sowohl um ganzheitliche Ansichten auf Clusterebene (z. B. wie man das gesamte Netzwerk und den Netzwerksicherheitsstatus des Clusters einfach einsehen kann) als auch um gezielte topografische Ansichten, um eine Reihe von Microservices aufzuschlüsseln und so bei der Fehlerbehebung oder Diagnose von Anwendungsproblemen zu helfen.

• Neue Wege zur Erkennung von Eindringlingen und zur Abwehr von Bedrohungen, einschließlich Warnmeldungen bei Richtlinienverstößen, Erkennung von Netzwerkanomalien und integrierte Bedrohungsmeldungen.

• Neue Abhilfe-Workflows, damit potenziell gefährdete Workloads während der forensischen Untersuchung schnell und sicher isoliert werden können.

• Neue Mechanismen zur Überprüfung von Konfigurations- und Richtlinienänderungen auf Einhaltung der Vorschriften.

• Neue Mechanismen für das Auditing von Konfigurations- und Richtlinienänderungen sowie Kubernetes-bezogene Netzwerkflussprotokolle, um Compliance-Anforderungen zu erfüllen (da herkömmliche Netzwerkflussprotokolle IP-basiert sind und im Kontext von Kubernetes wenig langfristige Bedeutung haben).

Wir werden ein Beispiel für eine typische Kubernetes-Bereitstellung in einem Unternehmen betrachten, um diese Herausforderungen zu verstehen. Abbildung 1-2 ist eine Darstellung eines gängigen Bereitstellungsmodells für Kubernetes und Microservices in einer Multi-Cloud-Umgebung. In einer Multi-Cloud-Umgebung setzt ein Unternehmen Kubernetes bei mehr als einem Cloud-Provider ein (Amazon Web Services, Google Cloud usw.). Eine hybride Cloud-Umgebung ist eine Umgebung, in der ein Unternehmen Kubernetes in mindestens einem Cloud-Provider einsetzt und eine Kubernetes-Installation vor Ort in seinem Rechenzentrum. Die meisten Unternehmen verfolgen eine Dual-Cloud-Strategie und betreiben Cluster in Amazon Web Services (AWS), Microsoft Azure oder Google Cloud; mehr Unternehmen haben auch einige Legacy-Anwendungen in ihren Rechenzentren laufen. Die Workloads im Rechenzentrum befinden sich wahrscheinlich hinter einem Sicherheitsgateway, das den Datenverkehr filtert, der über den Perimeter hereinkommt. Microservices, die in diesen Kubernetes-Implementierungen laufen, haben wahrscheinlich auch eine oder mehrere Abhängigkeiten von:

• Andere Cloud-Dienste wie AWS RDS oder Azure DB

• API-Endpunkte von Drittanbietern wie Twilio

• SaaS-Dienste wie Salesforce oder Zuora

• Datenbanken oder Legacy-Anwendungen, die im Rechenzentrum laufen

Die Workloads im Rechenzentrum befinden sich wahrscheinlich hinter einem Sicherheitsgateway, das den über den Perimeter eingehenden Datenverkehr filtert.

Observability in Kubernetes ist die Fähigkeit, aus gesammelten Metriken verwertbare Erkenntnisse über den Zustand von Kubernetes abzuleiten (mehr dazu später). Obwohl Observability auch in anderen Bereichen wie der Überwachung und Fehlerbehebung Anwendung findet, ist sie auch im Kontext der Netzwerksicherheit wichtig. Observability-Konzepte, die auf Flow-Logs in Verbindung mit anderen Kubernetes-Metadaten (Pods-Labels, Policies, Namensräume usw.) angewendet werden, dienen dazu, die Kommunikation zwischen Pods in einem Kubernetes-Cluster zu überwachen (und dann abzusichern), bösartige Aktivitäten durch den Vergleich von IP-Adressen mit bekannten bösartigen IP-Adressen zu erkennen und auf maschinellem Lernen basierende Verfahren zur Erkennung bösartiger Aktivitäten einzusetzen. Diese Themen werden im nächsten Abschnitt behandelt. Wie du in Abbildung 1-2 sehen kannst, stellt die Kubernetes-Bereitstellung eine Herausforderung dar, da die Daten in den einzelnen Clustern in Silos gespeichert sind und die Sichtbarkeit verloren gehen kann, wenn ein Workload in einem Cluster mit einem Workload in einem anderen Cluster oder mit einem externen Dienst verknüpft wird.

Abbildung 1-2. Beispiel für einen Kubernetes-Einsatz in einem Unternehmen

Wie in Abbildung 1-2 dargestellt, reicht der Footprint einer Microservices-Anwendung in der Regel über die Grenzen der Virtual Private Cloud (VPC) hinaus, und die Sicherung dieser Anwendungen erfordert einen anderen Ansatz als den traditionellen Perimeter-Sicherheitsansatz. Es ist eine Kombination aus Netzwerksicherheitskontrollen, Beobachtbarkeit, Bedrohungsabwehr und Unternehmenssicherheitskontrollen. Wir werden jeden dieser Punkte als Nächstes behandeln.

Netzwerksicherheitskontrollen

Native Sicherheitskontrollen von Cloud-Providern (z. B. AWS Security Groups oder Azure Network Security Groups) oder Sicherheitsgateways (z. B. Firewalls der nächsten Generation) am Rande der VPC oder des Rechenzentrums verstehen die Identität eines Microservice innerhalb eines Kubernetes-Clusters nicht. Du kannst zum Beispiel den Datenverkehr zu oder von einem Kubernetes Pod oder Service nicht mit deinen Sicherheitsgruppenregeln oder Firewall-Richtlinien filtern. Wenn der Datenverkehr von einem Pod auf das Netzwerk eines Cloud-Providers oder eine Firewall eines Drittanbieters trifft, wird der Datenverkehr außerdem (je nach Architektur des Cloud-Providers) mit einer Source Network Address Translation (SNAT) versehen. Mit anderen Worten: Die Quell-IP-Adresse des Datenverkehrs aller Workloads auf dem Knoten wird auf die IP-Adresse des Knotens gesetzt, so dass jede Art von Erlaubnis-/Verweigerungsrichtlinien bestenfalls eine Granularität auf Knotenebene (die IP-Adresse des Knotens) hat.

Kubernetes-Workloads sind sehr dynamisch und flüchtig. Nehmen wir an, ein Entwickler gibt ein neues Check-in für einen bestimmten Workload ab. Der automatisierte CI/CD-Workflow setzt ein, erstellt eine neue Version des Pods (Containers) und beginnt, diese neue Version des Workloads in Kubernetes-Clustern zu verteilen. Der Kubernetes-Orchestrator führt ein rollierendes Upgrade durch und stellt neue Instanzen des Workloads bereit. All dies geschieht auf automatisierte Weise und es gibt keinen Raum für manuelle oder außerbörsliche Workflows, um die Sicherheitskontrollen für den neu bereitgestellten Workload neu zu konfigurieren.

Du brauchst eine neue Sicherheitsarchitektur, um Workloads in einer Multi- oder Hybrid-Cloud-Infrastruktur abzusichern. Genau wie die Bereitstellung von Workloads in einem Kubernetes-Cluster muss auch die Sicherheit der Workloads als Code in einem deklarativen Modell definiert werden. Die Sicherheitskontrollen müssen über Kubernetes-Distributionen, Clouds, Infrastrukturen und/oder Netzwerke hinweg übertragbar sein. Wenn also eine neue Version des Workloads in einer VPC für den Amazon Elastic Kubernetes Service (EKS) anstelle von On-Premise-Clustern bereitgestellt wird, kannst du sicher sein, dass die mit dem Service verbundenen Sicherheitskontrollen nahtlos durchgesetzt werden, ohne dass du die Netzwerktopologie, die Out-of-Band-Konfiguration von Sicherheitsgruppen oder VPC/Perimeter-Firewalls überarbeiten musst.

Die Netzwerksicherheitskontrollen werden mit einer Netzwerkrichtlinienlösung implementiert, die nativ in Kubernetes ist und granulare Zugriffskontrollen ermöglicht. Es gibt mehrere bekannte Implementierungen von Netzwerkrichtlinien (z. B. Calico, Weave Net, Kube-router, Antrea), die du verwenden kannst. Zusätzlich zur Anwendung von Richtlinien auf Layer 3/Layer 4 (TCP/IP) empfehlen wir dir, dich nach Lösungen umzusehen, die Richtlinien für die Anwendungsebene (wie HTTP/HTTPS) unterstützen. Wir empfehlen außerdem, eine Lösung zu wählen, die auf dem beliebten Proxy Envoy basiert, da dieser für Richtlinien auf der Anwendungsebene weit verbreitet ist. Kubernetes unterstützt die Bereitstellung von Anwendungen als Microservices (kleine Komponenten, die einen Teil der Anwendungsfunktionalität bereitstellen) über ein Netzwerk von Knoten. Die Kommunikation zwischen Microservices basiert auf Anwendungsprotokollen wie HTTP. Daher sind granulare Anwendungskontrollen erforderlich, die durch Richtlinien auf der Anwendungsebene umgesetzt werden können. In einer dreistufigen Anwendung darf der Frontend-Microservice beispielsweise nur HTTP GET-basierte Anfragen an den Backend-Datenbank-Microservice stellen (Lesezugriff) und keine HTTP POST-Anfragen an den Backend-Datenbank-Microservice stellen (Schreibzugriff). Alle diese Anfragen können über dieselbe TCP-Verbindung laufen. Deshalb ist es wichtig, eine Policy Engine hinzuzufügen, die Kontrollen auf Anwendungsebene unterstützt, wie hier beschrieben.

Sicherheitskontrollen im Unternehmen

Nachdem du nun die Strategie für die Zugriffskontrollen im Netzwerk und die Beobachtbarkeit festgelegt hast, solltest du weitere Sicherheitskontrollen in Betracht ziehen, die wichtig und in Unternehmen weit verbreitet sind. Die Verschlüsselung von Daten während der Übertragung ist eine wichtige Voraussetzung für Sicherheit und Compliance. Es gibt mehrere Optionen für die Verschlüsselung, z. B. TLS-basierte Verschlüsselung in deinen Workloads, gegenseitiges TLS, das Teil einer Service-Mesh-Plattform ist, oder ein VPN-basierter Ansatz wie Wireguard (das ein kryptoschlüsselbasiertes VPN bietet).

Wir empfehlen dir, die Datenerfassung, die Teil deiner Beobachtungsstrategie ist, zu nutzen, um die Berichte zu erstellen, die du für die Einhaltung von Standards wie PCI, HIPAA, GDPR und SOC 2 benötigst. Die deklarative Natur von Kubernetes kann dir bei der Entwicklung und Umsetzung einer kontinuierlichen Compliance helfen. Du kannst zum Beispiel auf einen Pod reagieren, der bei einer Compliance-Prüfung fehlschlägt, indem du den Compliance-Status des Pods nutzt, um die notwendigen Maßnahmen zur Korrektur der Situation auszulösen (z. B. ein Image-Update).

Abwehr von Bedrohungen

Die Abwehr von Bedrohungen in einem Kubernetes-Cluster ist die Fähigkeit, bösartige Aktivitäten im Cluster zu erkennen und den Cluster davor zu schützen. Böswillige Aktivitäten ermöglichen es einem Angreifer, unbefugten Zugang zu erhalten und Daten aus einem Kubernetes-Cluster zu manipulieren oder zu stehlen. Die böswillige Aktivität kann in vielen Formen auftreten, z. B. durch das Ausnutzen einer unsicheren Konfiguration oder einer Schwachstelle im Anwendungsverkehr oder im Anwendungscode.

Wenn du eine Strategie zur Abwehr von Bedrohungen entwickelst, musst du sowohl die Erkennung als auch die Abwehr von Eindringlingen berücksichtigen. Der Schlüssel zur Erkennung von Eindringlingen ist die Beobachtbarkeit; du musst die gesammelten Daten überprüfen, um nach bekannten Bedrohungen zu suchen. Bei einem Kubernetes-Einsatz ist die Datenerfassung aufgrund der großen Datenmenge, die du überprüfen musst, eine große Herausforderung. Wir haben diese Frage schon oft gehört: "Brauche ich einen Kubernetes-Cluster, um Daten zur Verteidigung eines Kubernetes-Clusters zu sammeln?" Die Antwort lautet "Nein". Wir empfehlen dir, deine Beobachtungsstrategie mit der Erkennung von Eindringlingen abzustimmen und eine intelligente Aggregation zu nutzen, um Daten zu sammeln und zu prüfen. Du kannst zum Beispiel ein Tool verwenden, das Daten als Gruppen "ähnlicher" Pods aggregiert, die über einen bestimmten Zielport und ein bestimmtes Protokoll miteinander kommunizieren, anstatt die traditionelle Methode der Aggregation nach dem Fünfer-Tupel (Quell-IP, Quellport, Ziel-IP, Zielport, Protokoll) zu verwenden. Dieser Ansatz trägt dazu bei, die gesammelten Daten deutlich zu reduzieren, ohne die Effektivität zu beeinträchtigen. Erinnere dich daran, dass mehrere Pods, die mit demselben Container-Image arbeiten und auf dieselbe Weise eingesetzt werden, den gleichen Netzwerkverkehr für eine Transaktion erzeugen. Du fragst dich vielleicht: "Was ist, wenn nur eine Instanz infiziert ist? Wie kann ich das erkennen?" Das ist eine gute Frage. Es gibt mehrere Möglichkeiten. Du könntest ein Tool wählen, das maschinelles Lernen auf der Grundlage verschiedener gesammelter Metriken wie Verbindungen, Bytes und Pakete unterstützt, um anomale Arbeitslasten zu erkennen. Ein anderer Ansatz ist ein Tool, das bekannte bösartige IPs und Domains aus bekannten Bedrohungsdatenbanken als Teil der Sammlung erkennt und abgleicht oder unaggregierte Netzwerkflüsse für den durch Richtlinien verweigerten Verkehr protokolliert. Dies sind einfache Techniken, die dir helfen, eine Strategie zu entwickeln. Beachte, dass sich die Techniken zur Bedrohungsabwehr weiterentwickeln und dass du ein Sicherheitsforschungsteam brauchst, das mit dir zusammenarbeitet, um deine Anwendung zu verstehen und ein Bedrohungsmodell zu erstellen, mit dem du deine Bedrohungsabwehrstrategie umsetzen kannst.

Beobachtbarkeit

Die Beobachtbarkeit ist sehr nützlich für die Überwachung und Sicherung eines verteilten Systems wie Kubernetes. Kubernetes abstrahiert viele Details, und um ein solches System zu überwachen, kannst du keine einzelnen Metriken (wie einen einzelnen Netzwerkfluss, ein Pod-Erstellungs-/Destroy-Ereignis oder eine CPU-Spitze auf einem Knoten) erfassen und unabhängig voneinander überwachen. Wir brauchen eine Möglichkeit, diese Kennzahlen im Kontext der Kubernetes zu überwachen. Ein Pod, der mit einem Dienst oder einem Deployment verbunden ist, wird beispielsweise neu gestartet und läuft als eine andere Binary im Vergleich zu seinen Peers, oder eine Pod-Aktivität (Netzwerk, Dateisystem, Kernel-Systemaufrufe) unterscheidet sich von anderen Pods im Deployment. Noch komplexer wird es, wenn du eine Anwendung betrachtest, die mehrere Dienste (Microservices) umfasst, die wiederum von mehreren Pods unterstützt werden.

Observability ist nützlich bei der Fehlersuche und der Überwachung der Sicherheit von Workloads in Kubernetes. Mit Observability im Kontext eines Dienstes in Kubernetes kannst du z. B. Folgendes tun:

• Visualisiere deinen Kubernetes-Cluster als Service-Diagramm, das zeigt, wie Pods mit Services verbunden sind und wie die Kommunikation zwischen den Services abläuft

• Überlagerung von Anwendungs- (Layer 7) und Netzwerkverkehr (Layer 3/Layer 4) auf dem Service-Diagramm als getrennte Schichten, die es dir ermöglichen, Verkehrsmuster und Verkehrslast für Anwendungen und für das zugrunde liegende Netzwerk leicht zu bestimmen

• Zeigen Sie die Metadaten des Knotens an, auf dem ein Pod eingesetzt wird (z. B. Details zu CPU, Speicher oder Host-Betriebssystem).

• Metriken zum Betrieb eines Pods, zur Verkehrslast, zur Anwendungslatenz (z. B. HTTP-Dauer), zur Netzwerklatenz (Netzwerk-Roundtrip-Zeit) oder zum Pod-Betrieb (z. B. RBAC-Richtlinien, Servicekonten oder Container-Neustarts) anzeigen

• DNS-Aktivität (DNS-Antwortcodes, Latenz, Last) für einen bestimmten Dienst (Pods, die den Dienst unterstützen) anzeigen

• Verfolge eine Benutzertransaktion, die eine Kommunikation über mehrere Dienste hinweg erfordert; dies wird auch als verteiltes Tracing bezeichnet

• Ansicht der Netzwerkkommunikation eines bestimmten Dienstes mit externen Stellen

• Kubernetes-Aktivitätsprotokolle (z. B. Audit-Protokolle) für Pods und Ressourcen, die mit einem bestimmten Dienst verbunden sind, anzeigen.

Wir werden die Details der Beobachtbarkeit und Beispiele dafür, wie sie zur Sicherheit beitragen kann, in den folgenden Kapiteln behandeln. In dieser Diskussion werden wir kurz beschreiben, wie du Beobachtbarkeit als Teil deiner Sicherheitsstrategie nutzen kannst.

Sichtbarkeit des Netzwerkverkehrs

Wie bereits erwähnt, ist eine Lösung erforderlich, die Netzwerkflüsse aggregiert auf Dienstebene mit Kontext wie Namensräumen, Labels, Dienstkonten oder Netzwerkrichtlinien bereitstellt, um Aktivitäten und Zugriffskontrollen, die auf den Cluster angewendet werden, angemessen zu überwachen. Es besteht beispielsweise ein großer Unterschied zwischen der Meldung, dass IP1 mit IP2 über Port 8080 kommuniziert hat, und der Meldung, dass Pods mit der Bezeichnung "Frontend" mit Pods mit der Bezeichnung "Backend" über bestimmte Ports oder Verkehrsmuster zwischen Pods in einem Kubernetes-Cluster kommuniziert haben. Mit diesen Berichten kannst du die Kommunikation von externen Entitäten überprüfen und IP-Adressen-basierte Threat-Feeds anwenden, um Aktivitäten von bekannten bösartigen IP-Adressen oder sogar Datenverkehr von unerwarteten geografischen Standorten zu erkennen. Einzelheiten zu diesen Konzepten werden wir in Kapitel 11 behandeln.

DNS-Aktivitätsprotokolle

Das Domain Name System (DNS) ist ein System, mit dem die Namen der Domain in IP-Adressen übersetzt werden. In deinem Kubernetes-Cluster ist es wichtig, die DNS-Aktivitätsprotokolle zu überprüfen, um unerwartete Aktivitäten zu erkennen, z. B. Abfragen an bekannte bösartige Domains, DNS-Antwortcodes wie NXDOMAIN und unerwartete Steigerungen von Bytes und Paketen bei DNS-Abfragen. Einzelheiten zu diesen Konzepten werden wir in Kapitel 11 behandeln.

Sichtbarkeit des Anwendungsverkehrs

Wir empfehlen dir, den Datenverkehr der Anwendung auf verdächtige Aktivitäten wie unerwartete Antwortcodes und seltene oder bekannte bösartige HTTP-Header (User-Agent, Abfrageparameter) zu überprüfen. HTTP ist das in Kubernetes-Einsätzen am häufigsten verwendete Protokoll. Daher ist es wichtig, dass du mit deinem Sicherheitsforschungsteam zusammenarbeitest, um den HTTP-Datenverkehr auf böswillige Aktivitäten zu überwachen. Falls du andere Anwendungsprotokolle verwendest (z. B. Kafka, MySQL), musst du das Gleiche auch für diese tun.

Kubernetes-Aktivitätsprotokolle

Zusätzlich zu den Netzwerkaktivitätsprotokollen musst du auch die Aktivitätsprotokolle von Kubernetes überwachen, um bösartige Aktivitäten zu erkennen. Überprüfe zum Beispiel die Zugriffsverweigerungsprotokolle für den Zugriff auf Ressourcen und die Erstellung/Änderung von Dienstkonten. Überprüfe die Logs für die Erstellung/Änderung von Namensräumen auf unerwartete Aktivitäten. Und überprüfe die Kubernetes-Audit-Logs, die Anfragen an die Kubernetes-API aufzeichnen.

Maschinelles Lernen/Anomalieerkennung

Maschinelles Lernen ist eine Technik, bei der ein System in der Lage ist, Muster aus Daten über einen bestimmten Zeitraum abzuleiten. Das Ergebnis ist ein maschinelles Lernmodell, das dann verwendet werden kann, um Vorhersagen zu treffen und Abweichungen in realen Daten auf der Grundlage der Vorhersage zu erkennen. Wir empfehlen dir, die auf maschinellem Lernen basierende Erkennung von Anomalien auf verschiedene Metriken anzuwenden, um seltsame Aktivitäten zu erkennen. Eine einfache und effektive Methode ist die Anwendung einer maschinellen Lerntechnik, die als Baselining bekannt ist, auf einzelne Kennzahlen. Auf diese Weise musst du dich nicht um die Anwendung von Regeln und Schwellenwerten für jede einzelne Kennzahl kümmern; das System übernimmt das für dich und meldet Abweichungen als Anomalien. Die Anwendung von Techniken des maschinellen Lernens auf den Netzwerkverkehr ist ein relativ neuer Bereich, der bei den Sicherheitsteams immer mehr an Bedeutung gewinnt. Wir werden dieses Thema in Kapitel 6 ausführlich behandeln.

Es gibt viele Lösungen, die du für deine Observability-Strategie für Kubernetes wählen kannst (Datadog, Calico Enterprise, Cloud-Provider-basierte Lösungen von Google, AWS, Azure).

Sicherheits-Frameworks

Schließlich möchten wir dich noch auf die Sicherheits-Frameworks aufmerksam machen, die der Branche eine gemeinsame Methodik und Terminologie für bewährte Methoden im Sicherheitsbereich bieten. Sicherheitsframeworks sind eine gute Möglichkeit, um Angriffstechniken und bewährte Methoden zur Abwehr und Entschärfung von Angriffen zu verstehen. Du solltest sie nutzen, um deine Sicherheitsstrategie zu entwickeln und zu validieren. Bitte beachte, dass diese Frameworks nicht unbedingt spezifisch für Kubernetes sind, aber sie bieten Einblicke in die Techniken, die von Angreifern bei Angriffen verwendet werden, und Sicherheitsforscher müssen prüfen, ob sie für Kubernetes relevant sind. Wir werden zwei bekannte Frameworks untersuchen - MITRE und Threat Matrix für Kubernetes.

MITRE

MITRE ist eine Wissensdatenbank über Taktiken und Techniken von Angreifern basierend auf realen Beobachtungen von Cyberangriffen. Die MITRE ATT&CK® Matrix für Unternehmen ist nützlich, weil sie die Taktiken und Techniken für jede Stufe der Cybersecurity-Kill-Chain kategorisiert. Die Kill Chain ist eine Beschreibung der Phasen eines Cyberangriffs und ist nützlich, um eine effektive Verteidigung gegen einen Angriff aufzubauen. MITRE bietet auch eine Angriffsmatrix, die auf Cloud-Umgebungen wie AWS, Google Cloud und Microsoft Azure zugeschnitten ist.

Abbildung 1-3 beschreibt die MITRE ATT&CK® Matrix für AWS. Wir empfehlen dir, jede der in der Angriffsmatrix beschriebenen Phasen zu überprüfen, wenn du dein Bedrohungsmodell zur Sicherung deines Kubernetes-Clusters erstellst.

Abbildung 1-3. Angriffsmatrix für Cloud-Umgebungen in AWS

Bedrohungsmatrix für Kubernetes

Das andere Framework ist eine Bedrohungsmatrix , die eine Kubernetes-spezifische Anwendung der generischen MITRE-Angriffsmatrix ist. Sie wurde vom Microsoft-Team auf der Grundlage von Sicherheitsforschung und realen Angriffen veröffentlicht. Dies ist eine weitere hervorragende Ressource, um deine Sicherheitsstrategie zu entwickeln und zu validieren.

Abbildung 1-4 zeigt die Phasen, die für deinen Kubernetes-Cluster relevant sind. Sie entsprechen den verschiedenen Phasen, die wir in diesem Kapitel besprochen haben. So solltest du beispielsweise die kompromittierten Images in der Registry in der Phase des Erstzugriffs, die Cloud-Ressourcen in der Phase der Privilegienerweiterung und das interne Netzwerk des Clusters in der Phase der lateralen Bewegung für die Build-, Deploy- und Runtime-Sicherheit berücksichtigen.

Abbildung 1-4. Bedrohungsmatrix für Kubernetes

Sicherheit und Beobachtbarkeit

In einer dynamischen Umgebung wie Kubernetes kann ein sicheres Deployment deiner Anwendungen erreicht werden, indem du über Sicherheit und Beobachtbarkeit zusammen nachdenkst. Du musst zum Beispiel deinen Cluster "beobachten", um den optimalen Weg für die Implementierung von Kontrollen zur Sicherung des Clusters zu finden. Kubernetes als Orchestrierungs-Engine findet großen Anklang, weil es deklarativ ist und es den Nutzern ermöglicht, Ergebnisse auf höherer Ebene zu spezifizieren. Kubernetes verfügt außerdem über integrierte Funktionen, die sicherstellen, dass dein Cluster gemäß den Spezifikationen funktioniert. Dazu überwacht es die verschiedenen Attribute und ergreift Maßnahmen (z. B. einen Pod-Neustart), wenn das Attribut über einen bestimmten Zeitraum vom vorgegebenen Wert abweicht. Diese Aspekte von Kubernetes erschweren die Implementierung der Sichtbarkeit und der Kontrollen, die für die Sicherheit eines Clusters erforderlich sind. Die Kontrollen, die du implementierst, müssen auf die Kubernetes-Abläufe abgestimmt sein. Bevor du daran denkst, Kubernetes mit Kontrollen auszustatten, ist es daher wichtig, den Kontext zu verstehen: Du kannst zum Beispiel einen Pod nicht isolieren, indem du ihm eine Richtlinie auferlegst, die es ihm verbietet, mit anderen zu kommunizieren. Kubernetes erkennt, dass der Pod nicht mit anderen Elementen (z. B. dem API-Server) kommunizieren kann, stellt fest, dass der Pod nicht wie vorgesehen funktioniert, und startet den Pod an einem anderen Ort im Cluster neu und lässt ihn weiterlaufen.

Du musst zuerst verstehen, wie der Pod funktioniert und was sein erwarteter Betrieb ist, um dann Kontrollen anzuwenden oder unerwartete Ereignisse zu erkennen. Danach stellst du fest, ob es sich bei dem unerwarteten Ereignis um ein betriebliches Problem oder ein Sicherheitsproblem handelt, und wendest dann die erforderlichen Abhilfemaßnahmen an. Um dies zu erreichen, gehen Beobachtbarkeit und Sicherheit Hand in Hand: Du beobachtest, um zu verstehen, was erwartet wird, und wendest Kontrollen an, um den erwarteten Betrieb zu gewährleisten. Dann beobachtest du, um unerwartete Ereignisse zu erkennen und zu analysieren, und fügst dann die notwendigen Kontrollen hinzu, um Probleme zu beheben, die durch das Ereignis verursacht wurden. Deshalb brauchst du einen ganzheitlichen Ansatz für Sicherheit und Beobachtbarkeit, wenn du an die Sicherung deiner Cluster denkst.

Fazit

Jetzt solltest du einen Überblick darüber haben, was Kubernetes Sicherheit und Beobachtbarkeit bedeutet. Das sind die grundlegenden Konzepte, auf denen das gesamte Buch basiert. Zusammengefasst:

• Sicherheit für Kubernetes unterscheidet sich stark von traditioneller Sicherheit und erfordert einen ganzheitlichen Sicherheits- und Beobachtungsansatz in allen Phasen der Workload-Bereitstellung - Build, Deploy und Runtime.

• Kubernetes ist deklarativ und abstrahiert die Details der Workload-Operationen, was bedeutet, dass Workloads überall in einem Netzwerk von Knoten ausgeführt werden können. Außerdem können Workloads ephemer sein, d.h. sie werden zerstört und auf einem anderen Knoten neu erstellt. Um ein solches deklaratives verteiltes System zu sichern, musst du in allen Phasen an die Sicherheit denken.

• Wir hoffen, dass du verstehst, wie wichtig die Zusammenarbeit zwischen den Anwendungs-, Plattform- und Sicherheitsteams bei der Entwicklung und Umsetzung eines ganzheitlichen Sicherheitsansatzes ist.

• MITRE und die Bedrohungsmatrix für Kubernetes sind zwei Sicherheits-Frameworks, die von Sicherheitsteams weit verbreitet sind.

Es ist wichtig, dass du all dies zusammen betrachtest, denn eine erfolgreiche Sicherheits- und Beobachtungsstrategie ist eine ganzheitliche Strategie. Im nächsten Kapitel werden wir uns mit der Sicherheit der Infrastruktur befassen.