Compliance und Risiko
Drei Säulen der Kubernetes-Sicherheit
Kubernetes-Cluster sind standardmäßig unsicher und erfordern daher besondere Aufmerksamkeit bei deren Absicherung. Wir stellen Tools für die drei Säulen des Cluster-Schutzes vor: Image-Scanning, Zutrittskontrollen und Laufzeitsicherheit.
Save to Folio
Kubernetes, auch bekannt als K8s, ist eine sehr komplexe Open-Source-Plattform, die eines deutlichen Fokus auf Sicherheit bedarf. Trotz früherer Bemühungen, die Security zu erhöhen, bleibt Kubernetes standardmäßig unsicher und erfordert verschiedene Sicherheits-Tools zum Schutz des Clusters. Wir haben bereits dargelegt, wie Bedrohungsmodellierung hilft, Sicherheitsprobleme in diesen Clustern frühzeitig zu erkennen und zu beheben. Die 4 Cs der Cloud-nativen Sicherheitssysteme decken die Dreiergruppe der K8s-Sicherheitstools ab: Image-Scanning, Zutrittskontrollen und Laufzeitsicherheit:
Obwohl es viele andere Optionen auf dem Markt gibt, sind dies die einzigen erforderlichen Instrumente, die aus Sicht der Industrie die wichtigsten sind.
Image Scanning
In Kubernetes-Clustern werden Pods eingesetzt, die kleinste Einheit von K8s-Workloads. Jeder Pod kann Speicher- und Netzwerkressourcen gemeinsam nutzen und einen oder mehrere Container enthalten. Bevor die Container im Cluster ausgeführt werden, muss sichergestellt sein, dass sie vertrauenswürdig sind und keine ernsthaften Sicherheitsprobleme aufweisen. Dies wird über Image-Scanning oder Container-Scanning erreicht.
Image-Scanning untersucht ein bestimmtes Container-Image auf eine Reihe von Sicherheitsproblemen. Dabei kann es sich um Fehlkonfigurationen, Schwachstellen oder in manchen Fällen auch um Malware handeln. Das Scanning prüft in jeder Ebene des Container-Images (Container bestehen aus mehreren Ebenen), ob die dort installierte oder konfigurierte Software ein öffentlich bekanntes Sicherheitsproblem aufweist. Dieser Prozess nutzt in der Regel eine öffentliche Schwachstellen-Datenbank wie die National Vulnerability Database (NVD), die Open Source Vulnerability (OSV) Database oder die GitHub Security Advisory (GHSA) Database. Einige kommerzielle Tools können auch ihre private Schwachstellendatenbank verwenden.
Einige Images werden auch auf der Grundlage eines anderen Container-Images (dem so genannten Basis-Image) erstellt. Das bedeutet, dass das neue Image jede Schwachstelle erbt, die im Basis Image vorhanden ist. Dies ist wichtig, da eine Änderung des Basis-Images die im endgültigen Image gefundenen Schwachstellen manchmal drastisch reduzieren kann. Einige Tools, wie der Befehl docker scan, schlagen die sichersten Basis-Images vor.
Als wir in unserem jüngsten Linux Threat Report die 15 beliebtesten offiziellen Docker Images auf Docker Hub analysierten, wiesen alle mindestens eine kritische Sicherheitslücke auf. Wer keine Container von Grund auf neu erstellt oder winzige Images wie Alpine Linux verwendet, sollte eine Sicherheitsrichtlinie für seine Container-Images erstellen und durchsetzen. Eine andere Lösung ist die Verwendung der Distroless-Technik.
Clair: Clair war einer der ersten Open-Source-Image-Scanner - und ist derzeit auch einer der beliebtesten. Er wurde in Go entwickelt und wird von der Quay-Organisation gepflegt, die Teil von Red Hat in IBM ist. Er extrahiert Container-Inhaltsinformationen über seine Schichten und identifiziert potenzielle Sicherheitsschwachstellen. Es gibt mehrere Möglichkeiten des Einsatzes: Sie können die neueste auf GitHub veröffentlichte Version verwenden oder auch eine lokale Entwicklungsumgebung mit dem GitHub-Repository und Docker Compose zu Testzwecken einrichten.
Docker Scout: Der neue Docker Scout-Befehl, früher als Docker Scan bekannt, befindet sich immer noch in einer frühen Entwicklungsphase. Verwenden Sie Docker CLI, so kann der Befehl zum Scannen und Prüfen der Schwachstelle in den Docker Images dienen.
Die Wirksamkeit des Scan-Vorgehens hängt von der Qualität, Organisation und Pflege der Schwachstellendatenbank ab. Sich nur auf eine öffentliche Schwachstellendatenbank wie die National Vulnerability Database (NVD) zu verlassen, ist in der Regel nicht ausreichend.
Admission Controller
Zugangskontroll-Tools kümmern sich um den Zugang von K8s-Objekten zu einem Cluster. Der kube-apiserver ruft die Zugangskontroll-Tools nach der Authentifizierung und Autorisierung auf.
Es gibt drei Typen von Zugangskontroll-Tools:
- Ändernd - kann die Objekte in der Anfrage ändern.
- Validierend - validiert nur die aktuelle Objektstruktur und -information.
- Beides - führt sowohl ändernde als auch prüfende Funktionen aus.
In Kubernetes stehen mehrere Zugangs-Controller zur Verfügung. Eine vollständige Liste der nativen Controller gibt es in der K8s-Dokumentation. Den Sinn und die Funktionsweise sollen zwei konkrete Beispiele erläutern.
Open Policy Agent (OPA) und Gatekeeper
Open Policy Agent (OPA) ist ein bekannter Cloud-nativer Policy Agent, mit dem sich Richtlinien für Continuous Integration (CI) / Continuous Deployment/Delivery (CD)-Pipelines, API Gateways u.a. erstellen lassen. Diese Richtlinien sollen sicherstellen, dass sich die Anwendung wie erwartet verhält und Compliance-Anforderungen durchgesetzt werden, z. B. dass jedes Container Image vor der Bereitstellung gescannt wird. Eine speziellere Version davon für K8s ist Gatekeeper. Er nutzt die Leistungsfähigkeit der Rego-Engine von OPA und die nativen K8s-Ressourcen für die Zugangskontrolle von Kubernetes. Die Installation beschreibt der Originalbeitrag.
Kyverno
Kyverno ist ein weiteres Tool, das der Zugangskontrolle in einem K8s-Cluster dient. Es ist nicht erforderlich, eine neue Sprache zu erlernen (wie bei OPA mit Rego). Es kann die an den K8s-API-Server gesendeten Anfragen ändern oder validieren.
Kyverno erstellt einen Zugangs-Controller, der ändernde und validierende Anfragen vom kube-apiserver unter Anwendung von Richtlinien und Regeln verarbeitet. Basierend auf diesen Richtlinien und Regeln kann Kyverno die Anfrage blockieren, wenn die Validierung auf „erzwingen“ eingestellt ist, oder die Anfrage zulassen und das Problem protokollieren, wenn die Validierung auf „prüfen“ lautet. Weitere Einzelheiten beinhaltet der Originalbeitrag.
Pod Security Policy und Pod Security Admission
Beim Thema Admission Controller ist der Unterschied zwischen der veraltete Pod Security Policy (PSP) und die neue Pod Security Admission zu beachten. PSP war eine frühere Version des Admission Controllers, mit deren Hilfe eine Reihe von Berechtigungs- und Zugriffskontrolleinstellungen für Pods festgelegt werden konnten, auch als Sicherheitskontext bekannt. Weitere Einzelheiten dazu beinhalten der Originalbeitrag und die offizielle Dokumentation von K8s.
PSPs sind seit Kubernetes Version 1.21 veraltet und wurden mit Version 1.25, die im Oktober 2023 ihr End of Life (EOL) erreichte, vollständig entfernt. Nutzer dieser Versionen sollten ihre Cluster auf aktuelle Versionen aktualisieren.
Die neue Pod Security Admission befindet sich derzeit im Beta-Stadium und ist seit Kubernetes Version 1.23 standardmäßig aktiviert. Dieser neue eingebaute Zulassungs-Controller ermöglicht es, die Pods auf der Grundlage von drei Sicherheitsstufen zu kategorisieren:
- Privilegiert - bietet uneingeschränkten Zugriff und ermöglicht die Ausweitung von Privilegien.
- Baseline - bietet minimale Einschränkungen und ist die Standard-Pod-Konfiguration.
- Eingeschränkt - mit starken Einschränkungen, folgt den Best Practices zur Pod-Härtung.
Teams können auch den Modus der Zugangskontrolle festlegen, den sie für ihre Pods in jedem Namensraum durchsetzen möchten. Dies sind: erzwingen, auditieren und warnen.
Auch dazu finden Sie weitere Einzelheiten im Originalbeitrag.
Laufzeitsicherheit
Der letzte Pfeiler der Sicherheit von Kubernetes-Clustern bezieht sich darauf sicherzustellen, dass die laufenden Container nach der Ausführung nicht verändert werden. Das bedeutet zu gewährleisten, dass die auf dem Cluster ausgeführten Container mit dem Inhalt des Container-Images übereinstimmen.
Laufzeitsicherheit lässt sich mit dem Schiedsrichter bei einem Fußballspiel vergleichen. Sie sehen was auf dem Spielfeld passiert, und überwachen, was die einzelnen Spieler (Pods oder Container) tun. Die Laufzeitsicherheit kann verdächtige Verhaltensweisen erkennen und melden, sowie eine gelbe oder rote Karte zeigen. Diese Maßnahmen umfassen das Blockieren verdächtiger Aktivitäten oder das vollständige Entfernen aus dem Cluster.
Einer der Mechanismen, die in dieser Phase eingesetzt werden, ist „Drift Detection“. Der Mechanismus überprüft das ursprüngliche Image des Containers und vergleicht es mit dem aktuellen Zustand des laufenden Containers. Gibt es Unterschiede zwischen den beiden (z. B. laufende Prozesse, installierte Pakete), liegt eine Abweichung vor, und der Container wurde nach der Ausführung verändert.
Nach dem Prinzip der unveränderlichen Infrastruktur sollten Container nach der Ausführung nicht mehr verändert werden. Sie werden nicht gepatcht oder aktualisiert wie normale Server. Wann immer es einen Patch oder ein Update für ein Container Image gibt, muss eine neue Version des Images die alte ersetzen. Dieser Prozess stellt sicher, dass der Inhalt des Images immer mit dem übereinstimmt, was in der Produktionsumgebung ausgeführt wird.
Was aber, wenn ein Angreifer die Anwendung in einer Container-Umgebung kompromittiert und neue Software installiert, z. B. bösartige Pakete oder Miner für Kryptowährungen? Dies ist eines der Hauptziele der Laufzeitsicherheit - die Erkennung verdächtiger oder bösartiger Änderungen zur Laufzeit. Eine der führenden Technologien dafür ist eBPF.
eBPF
Viele Container-Sicherheitslösungen setzen eBPF (früher bekannt als erweiterter Berkeley Packet Filter) als zugrundeliegende Technologie ein. Sie ermöglicht die Ausführung von in Sandboxes laufenden oder isolierten Programmen innerhalb des Kernels eines Betriebssystems. Wir haben kürzlich gezeigt, wie Angreifer eBPF für bösartige Zwecke nutzen.
Falco
Falco ist eines der führenden Open-Source-Tools für Sicherheit und Überwachung. Es ist ein Projekt der Cloud Native Computing Foundation (CNCF) mit einer anpassbaren und flexiblen Regel-Engine, um verdächtige Verhaltensweisen auf den Systemen zu überwachen. Es ist als das Intrusion Detection System (IDS) für Container anerkannt. Weitere Einzelheiten umfasst der Originalbeitrag.
Fazit
Auch für die drei Kernkomponenten eines Kubernetes-Sicherheits-Toolset gilt wie bei der „Shift Security Left“-Strategie in DevSecOps: Je früher Sie Sicherheitsprobleme in Ihren Containern erkennen, desto einfacher und schneller können Sie sie beheben. Es ist wichtig zu verstehen, dass kein einzelnes Tool den Cluster vor Angriffen schützen kann, daher ist es wichtig, eine ganzheitliche Sicht auf die Sicherheit von Kubernetes zu haben. Auch kann eine „Defense in Depth“-Strategie helfen, wobei das Prinzip der geringsten Privilegien zum Einsatz kommt. Diese Strategien können letztlich helfen, die Auswirkungen eines Angriffs zu minimieren.