Kubernetes-Sicherheit: Häufige Probleme und Best Practices

Warum ist Kubernetes-Sicherheit wichtig?

Kubernetes-Sicherheit ist wichtig, weil Cluster und Pods vielfältigen Bedrohungen ausgesetzt sind, darunter:

• Böswillige Akteure

• In Containern ausgeführte Malware

• Fehlerhafte Container-Images

• Kompromittierte oder unbefugte Nutzer

Ohne geeignete Kontrollen könnte ein böswilliger Akteur, der in eine Anwendung eindringt, versuchen, die Kontrolle über den Host oder den gesamten Cluster zu übernehmen.

Welche Rolle spielt Kubernetes im gesamten Entwicklungsprozess?

Das folgende Diagramm zeigt, wo Kubernetes-Sicherheit in den gesamten Softwareentwicklungslebenszyklus (SDLC) eingebettet ist. Nach der Build-Phase wird der Code getestet, damit Schwachstellen nicht in die Live-Kubernetes-Umgebung gelangen. Deployment und Cloud-Infrastruktursicherheit überwachen anschließend laufende Anwendungen und geben Erkenntnisse an Entwickler weiter. So entsteht eine positive Feedbackschleife vom Code zur Cloud und wieder zurück zum Code.

Kubernetes-Sicherheit im SDLC

Zentrale Kubernetes-Sicherheitsprobleme

Es gibt zahlreiche Kubernetes-Sicherheitsprobleme. Die drei wichtigsten Aspekte sind:

1. Kubernetes-Sicherheitskontrollen konfigurieren: Wenn Sie Kubernetes selbst als Open-Source-Lösung bereitstellen, sind standardmäßig keine Sicherheitskontrollen konfiguriert. Wie sie funktionieren und wie Sie sie sicher konfigurieren, liegt vollständig in der Verantwortung des Betreibers.

2. Workloads sicher bereitstellen: Ganz gleich, ob Sie eine Kubernetes-Distribution mit vorkonfigurierten Sicherheitskontrollen verwenden oder einen Cluster samt Sicherheitsmaßnahmen selbst aufbauen: Entwickler und Anwendungsteams sind möglicherweise mit den Feinheiten von Kubernetes nicht vertraut und haben deshalb Schwierigkeiten, ihre Workloads angemessen abzusichern.

3. Keine integrierte Sicherheit: Kubernetes bietet zwar Zugriffskontrollen und Funktionen, mit denen sich ein sicherer Cluster erstellen lässt, doch die Standardeinrichtung ist nicht zu 100 % sicher. Unternehmen müssen die Workloads, den Cluster, das Netzwerk und die Infrastrukturkonfigurationen entsprechend anpassen, damit Kubernetes-Cluster und Container vollständig geschützt sind.

Kubernetes-Sicherheitsherausforderungen und Lösungen

Die integrierten Kubernetes-Sicherheitslösungen decken zwar nicht alle möglichen Probleme ab, doch im Kubernetes-Ökosystem gibt es zahlreiche Sicherheitslösungen.

In einigen anspruchsvollen Kubernetes-Bereichen sind zusätzliche Sicherheitstools erforderlich:

1. Workload-Sicherheit: Die meisten Kubernetes-Workloads sind Container, die auf Engines wie containerd, cri-o oder Docker ausgeführt werden. Der Code und die weiteren Pakete in diesen Containern müssen frei von Schwachstellen sein.

2. Workload-Konfiguration: Ganz gleich, ob Sie Kubernetes-Manifeste, Helm Charts oder Vorlagen-Tools verwenden: Die Konfiguration für das Deployment Ihrer Anwendungen in Kubernetes erfolgt in der Regel als Code. Dieser Code beeinflusst die Kubernetes-Sicherheitskontrollen, die festlegen, wie ein Workload ausgeführt wird und was im Falle eines Sicherheitsvorfalls passieren kann oder nicht. Wenn Sie beispielsweise CPU, Arbeitsspeicher und Netzwerk für jeden Workload auf die maximal erwartete Nutzung beschränken, lässt sich ein Sicherheitsvorfall auf den betroffenen Workload begrenzen und verhindern, dass andere Services kompromittiert werden.

3. Cluster-Konfiguration: Für laufende Cluster stehen verschiedene Kubernetes-Sicherheitsbewertungstools zur Verfügung, zum Beispiel Sysdig, Falco und Prometheus. Unter anderem nutzen diese Tools Audit-Logs und weitere integrierte Kubernetes-Metriken, um die Einhaltung von Kubernetes-Sicherheits-Best-Practices sowie von CIS- und anderen relevanten Sicherheits-Benchmarks zu überprüfen.

4. Kubernetes-Netzwerk: Die Netzwerksicherheit spielt eine zentrale Rolle bei Kubernetes. Pod-Kommunikation, Ingress, Egress, Service Discovery und – falls erforderlich – Service Meshes (z. B. Istio) müssen berücksichtigt werden. Sobald ein Cluster kompromittiert wurde, sind alle Services und Rechner im Netzwerk gefährdet. Deshalb müssen Ihre Services und die Kommunikation zwischen ihnen auf das Notwendige beschränkt werden. In Kombination mit Kryptografie, die Ihre Rechner und Services schützt, lässt sich so die Bedrohung ebenfalls eindämmen und ein schwerwiegender netzwerkweiter Sicherheitsvorfall verhindern.

5. Infrastruktursicherheit: Da verteilte Anwendungen auf vielen Servern ausgeführt werden (mit physischer oder virtueller Netzwerk- und Speicherinfrastruktur), ist die Absicherung Ihrer Kubernetes-Infrastruktur entscheidend – insbesondere der Master-Nodes, Datenbanken und Zertifikate. Wenn ein böswilliger Akteur erfolgreich in Ihre Infrastruktur eindringt, könnte er auch auf alles zugreifen, was zum Zugriff auf Ihren Cluster und Ihre Anwendungen erforderlich ist.

Jede dieser Herausforderungen lässt sich mit Sicherheitstools aus dem Kubernetes-Ökosystem angehen. Die Partnerschaft zwischen Snyk und Sysdig sorgt für eine engere Abstimmung zwischen Entwicklern und SecOps. Dafür stellt sie Developer-first-Tools für alle Aspekte der Kubernetes-Sicherheit bereit – vom Container bis zum Cluster. Snyk bietet entwicklerorientierte Sicherheitstools, die den gesamten SDLC abdecken, darunter Snyk Container und Snyk Open Source. Durch die Verbindung dieser Developer-first-Workflows mit Sysdig können Erkenntnisse aus Sysdigs Runtime Intelligence, die Audit-Logs zur Überwachung von Kubernetes-Umgebungen nutzt, direkt in die gewohnten Workflows von Entwicklern einfließen. Diese Partnerschaft ermöglicht die erste Developer-first-Plattform für das Cloud Security Posture Management.

Ergebnis des Kubernetes-Workload-Konfigurationsscans von Snyk

Kubernetes-Hosts absichern

Der Cloud-Host bildet die letzte Ebene einer Kubernetes-Umgebung. Die großen Cloud-Anbieter stellen Verwaltungstools für Kubernetes-Ressourcen bereit, darunter Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) und Amazons Elastic Kubernetes Service (EKS). Die Sicherheit basiert jedoch weiterhin auf einem Modell geteilter Verantwortung.

Es gibt mehrere Möglichkeiten, Kubernetes-Hosts vor Schwachstellen zu schützen:

• Workload-Ebene absichern: Stellen Sie sicher, dass Container-Images frei von Schwachstellen und korrekt konfiguriert sind (z. B. indem Sie privilegierte Container untersagen).

• Grenzen zwischen Workloads und Hosts schaffen: Beschränken Sie den Zugriff auf Host-Ressourcen, indem Sie Container-Berechtigungen reduzieren und die Laufzeitumgebung so konfigurieren, dass die Ressourcennutzung im Falle eines Sicherheitsvorfalls eingeschränkt wird.

• Laufende Cluster überwachen: Überwachen Sie Audit-Logs, um Fehlkonfigurationen oder verdächtiges Verhalten zu erkennen.

Kubernetes-Security-Context-Einstellungen, die Sie implementieren sollten

Eine Möglichkeit, Pods und Cluster daran zu hindern, auf den Rest des Kubernetes-Systems zuzugreifen, ist die Verwendung von securityContexts. Hier sind zehn wichtige Security-Context-Einstellungen, die jeder Pod und Container verwenden sollte:

1. runAsNonRoot: Wenn Sie diese Einstellung auf „true“ setzen, werden Container nicht als Root-Nutzer ausgeführt.

2. runAsUser / runAsGroup: Diese Einstellungen stellen sicher, dass Container einen festgelegten Nutzer und eine festgelegte Gruppe zur Laufzeit verwenden.

3. seLinuxOptions: Damit wird der SELinux-Kontext für den Container oder Pod festgelegt.

4. seccompProfile: Damit können Sie das seccomp-Profil im Linux-Kernel festlegen, um die Aktionen von Containern einzuschränken.

5. privileged / allowPrivilegeEscalation: Es wird generell nicht empfohlen, privilegierte Container oder eine Erhöhung der Berechtigungen von Prozessen darin zu erlauben. Diese Einstellungen sollten daher auf „false“ gesetzt werden.

6. capabilities: Damit können Sie den Zugriff auf Kernel-Aufrufe steuern. Gewähren Sie nur die mindestens erforderlichen Berechtigungen.

7. readonlyRootFilesystem: Setzen Sie diese Einstellung, wenn möglich, auf „true“. So können Angreifer keine Software installieren oder Dateisystemkonfigurationen ändern.

8. procMount: Verwenden Sie die Einstellung „Default“, außer in besonderen Situationen wie bei verschachtelten Containern.

9. fsGroup / fsGroupChangePolicy: Diese Einstellung sollte mit Vorsicht verwendet werden, da eine Änderung der Eigentümerschaft eines Volumes mit fsGroup die Startleistung von Pods beeinträchtigen und negative Auswirkungen auf gemeinsam genutzte Dateisysteme haben kann.

10. sysctls: Änderungen an Kernel-Parametern mit sysctls sollten vermieden werden, es sei denn, Sie haben ganz bestimmte Anforderungen. Andernfalls könnte das Host-System instabil werden.

Play Video: Kubernetes security with Snyk

Beobachtbarkeit der Kubernetes-Sicherheit

Für die K8s-Sicherheit helfen sichere Konfigurationen dabei, die Sicherheitsfunktionen von Kubernetes optimal zu nutzen. Ebenso wichtig sind wirksame Überwachungsprozesse, um den Überblick über Kubernetes-Ressourcen zu behalten. Hier finden Sie einige Tipps zur Kubernetes-Überwachung:

• Tags und Labels verwenden: Damit lassen sich Anwendungen mithilfe von Metadaten definieren und einfacher verwalten.

• Die gesamte Gruppe der Container statt einzelner Container überwachen: Kubernetes verwaltet Pods, keine Container. Deshalb ist die Überwachung auf Pod-Ebene wichtig.

• Service Discovery verwenden: Damit lassen sich Kubernetes-Services trotz ihrer flüchtigen Natur überwachen.

• Warnmeldungen nutzen: Sie können Warnmeldungen anhand der Kriterien einrichten, die eine intakte Kubernetes-Umgebung definieren. Achten Sie darauf, nicht zu viele Warnmeldungen auszulösen, da verteilte Systeme zahlreiche mögliche Überwachungsendpunkte haben können.

• Die Control Plane überprüfen:Die Kubernetes-Control-Plane fungiert wie eine Flugverkehrskontrolle für Workloads und Cluster. Die Überprüfung jeder Komponente der Control Plane trägt dazu bei, eine effiziente Orchestrierung und Planung von Jobs sicherzustellen.

Kubernetes-Sicherheits-Best-Practices nach Phase

Für die Kubernetes-Sicherheit gelten in den einzelnen Phasen folgende Best Practices:

Entwicklungs-/Designphase

• Manche Kubernetes-Umgebungen sind möglicherweise sicherer als andere. Eine Multi-Cluster-Architektur oder mehrere Namespaces mit geeigneten RBAC-Kontrollen können dabei helfen, Workloads voneinander zu isolieren.

Build-Phase

• Wählen Sie ein minimales Image aus einem geprüften Repository.

• Verwenden Sie Tools zum Container-Scanning, um Schwachstellen oder Fehlkonfigurationen in Containern aufzudecken.

Deployment-Phase

• Images sollten vor dem Deployment gescannt und validiert werden.

• Mit einem Admission Controller lässt sich diese Validierung automatisieren, sodass nur geprüfte Container-Images bereitgestellt werden.

Laufzeitphase

• Die Laufzeitumgebung bildet die letzte Verteidigungsebene für Kubernetes-Ressourcen.

• Die Kubernetes-API erstellt Audit-Logs, die mit einem Runtime-Security-Tool wie Sysdig überwacht werden sollten.

• Images und Richtliniendateien sollten außerdem kontinuierlich gescannt werden, um Malware oder Fehlkonfigurationen in einer Laufzeitumgebung zu verhindern.

Kubernetes-Sicherheit mit Snyk

Mit seinen Developer-first-Sicherheitstools, darunter Snyk Container und Snyk IaC, hilft Snyk Ihnen, Ihre Kubernetes-Sicherheitslage zu verbessern und aufrechtzuerhalten. Snyk automatisiert das Scannen von Anwendungscode, Container-Images und Kubernetes-Konfigurationen und stellt Entwicklern Erkenntnisse und Empfehlungen direkt in ihren Workflows bereit.

„Ein Produkt wie Snyk hilft uns dabei, Bereiche unserer Services zu identifizieren, die potenziell Bedrohungen durch externe Akteure ausgesetzt sind“, erklärte Rizzo. ... „Seit Snyk Teil unserer CI/CD-Pipeline ist, werden Sicherheitsprüfungen bereits in einer früheren Entwicklungsphase durchgeführt.“

Ciro Rizzo – Head of Engineering – The Telegraph

Unsere Partnerschaft mit Sysdig erweitert unsere Sicherheitsfunktionen auf die Laufzeitumgebung.

Häufig gestellte Fragen zur Kubernetes-Sicherheit