Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Kubernetes-Sicherheit 101: Grundlagen und Best Practices

Kubernetes-Sicherheit mag rätselhaft erscheinen. Da Kubernetes ein hochkomplexes System ist, das verschiedene Komponenten beinhaltet, reicht es für seinen Schutz nicht, einfach nur ein Sicherheitsmodul zu aktivieren oder ein Sicherheitstool zu installieren.

Zum Erreichen von Kubernetes-Sicherheit müssen Teams vielmehr alle Arten von Sicherheitsrisiken adressieren, die sich auf verschiedene Schichten und Services in einem Kubernetes-Cluster auswirken können. Zum Beispiel müssen Teams verstehen, wie sich Kubernetes-Knoten, -Netzwerke, -Pods, -Daten usw. sichern lassen.

Zudem müssen Kubernetes-Administratoren wissen, welche Tools Kubernetes zum Bewältigen von Sicherheitsaspekten nativ bereitstellt und welche Third-Party-Sicherheitstools sie benötigen, um ihre Cluster zu integrieren und Sicherheitslücken zu schließen. Das ist ein weiteres komplexes Thema: Kubernetes ist zwar keine Sicherheitsplattform, doch bietet die Lösung bestimmte native Sicherheitstools wie Role-Based Access Control (RBAC).

Wenn Sie Kubernetes-Anfänger sind und noch nicht wissen, wie alles zusammenhängt und man sich vor Bedrohungen schützt, können die genannten Punkte überwältigend erscheinen. Die Konzepte sind jedoch so simpel, dass sie sich in Form kleinerer Brocken verdauen lassen. Dazu gehen wir in diesem Artikel auf die verschiedenen Aspekte von Kubernetes-Sicherheit sowie auf deren Grundlagen ein. Zudem stellen wir Best Practices für Kubernetes-Sicherheit in allen Ebenen und Service-Leveln vor.

Kubernetes-Sicherheit – Stück für Stück

Die Annäherung an Kubernetes-Sicherheit fällt ggf. leichter, wenn Sie über die Arten von Risiken nachdenken, die einzelne Komponenten im Kubernetes-Stack betreffen können, und dann Tools und Ressourcen ermitteln, mit denen Sie diese Komponenten schützen können.

Sicherheit von Knoten

Knoten sind die Server, aus denen Kubernetes-Cluster bestehen. Meist führen Knoten eine bestimmte Version von Linux aus, doch laufen Workerknoten ggf. unter Windows. Knoten können virtuelle Maschinen oder Bare-Metal-Server sein, was aus der Sicherheitsperspektive aber keinen großen Unterschied macht.

Zum Schutz von Kubernetes-Knoten sollten Sie dieselben Sicherheitsstrategien verwenden, die Sie auch zum Schutz anderer Server nutzen. Dazu gehören:

  • Entfernen irrelevanter Applications, Bibliotheken und anderer Komponenten des Betriebssystems zur Minimierung der Angriffsfläche. Bereitstellen von Knoten mit minimalistischen Linux-Distributionen (zum Beispiel Alpine Linux) als Best Practice.
  • Eliminieren unnötiger Benutzerkonten.
  • Sicherstellen, dass eine Ausführung nur dann mit root-Berechtigung erfolgt, wenn es nicht anders geht.
  • Bereitstellen von Frameworks zur OS-Härtung wie AppArmor oder SELinux, wenn möglich.
  • Sammeln und Analysieren von OS-Logs zur Erkennung möglicher Sicherheitsverletzungen.

Wenn Sie in einer beliebigen Umgebung Erfahrung mit dem Schutz von Servern auf der Betriebssystemebene haben, wissen Sie wahrscheinlich bereits, wie man die Sicherheit von Kubernetes-Knoten richtig verwaltet. Auf der Knotenebene unterscheiden sich die Sicherheitsaspekte von Knoten, auf denen Kubernetes ausgeführt wird, kaum von jenen, die für andere Arten von Servern gelten.

Zwischen dem Schutz eines Masterknotens und dem Schutz eines Workerknotens gibt es keine fundamentalen Unterschiede. Der Schutz von Masterknoten ist etwas wichtiger, da Sicherheitsverletzungen bei einem Masterknoten in Ihrem Cluster mehr Schaden anrichten können. Das Verfahren zum Sichern des Betriebssystems auf einem Masterknoten ist jedoch das gleiche wie bei einem Workerknoten.

Sicherheit der Kubernetes-API

Die Kubernetes-API ist das Element, das die verschiedenen Teile eines Clusters zusammenhält. Darum ist die API eine der wichtigsten Ressourcen in Kubernetes, die geschützt werden muss.

Die Kubernetes-API wurde für standardmäßige Sicherheit entwickelt. Sie reagiert lediglich auf Anfragen, die sie richtig authentifizieren und autorisieren kann.

API-Authentifizierung und -Autorisierung werden dabei durch von Ihnen konfigurierte RBAC-Richtlinien gesteuert. Das heißt, dass die API nur so sicher ist wie Ihre RBAC-Richtlinien. Sichere RBAC-Richtlinien, die das Least-Privilege-Prinzip durchsetzen und Berechtigungen auf granularer Basis anwenden, stellen somit eine grundlegende Best Practice zur Gewährleistung der Sicherheit der Kubernetes-API dar.

Sie können die API-Sicherheit durch Einsatz von Zugangs-Controllern weiter erhöhen. Zugangs-Controller evaluieren Anfragen, nachdem der API-Server sie bereits authentifiziert und autorisiert hat. So fungieren Zugangs-Controller als optionale zweite Schutzschicht für Anfragen, die nicht zugelassen werden sollten. Durch Aktivieren und Konfigurieren von Zugangs-Controllern können Sie verschiedene Sicherheitsregeln im Zusammenhang mit API-Anfragen durchsetzen. Die verfügbaren Regeln sind hier dokumentiert. 

Zu guter Letzt lassen sich API-Anfragen auf der Netzwerkebene schützen, indem Sie sichere Zertifikate konfigurieren und dem API-Server vorschreiben, Anfragen an einem sicheren Port und nicht am Localhost zu übertragen.

Kubernetes-Netzwerksicherheit

Kubernetes-Netzwerksicherheit ähnelt Pod-Sicherheit in dem Sinne, dass Sie mit den gleichen Best Practices loslegen, die Sie zum Schutz eines beliebigen Netzwerks verwenden würden.

Soweit möglich sollten Sie eine Netzwerkinfrastruktur schaffen, die Workloads vom öffentlichen Internet isoliert, wenn sie nicht unbedingt darüber kommunizieren müssen. Auf der Gatewayebene sollten Sie Firewalls bereitstellen, um Datenverkehr von nicht konformen Hosts zu blockieren. Zudem sollten Sie Netzwerkverkehr auf Hinweise prüfen, die auf eine Sicherheitsverletzung hinweisen könnten. Das alles sind Schritte, die Sie mit externen Tools erledigen können (z. B. mit einem Service-Mesh).

Kubernetes bietet jedoch ebenfalls einige native Tools, mit denen sich Netzwerkressourcen schützen lassen. Diese Tools haben die Form von Netzwerkrichtlinien. Netzwerkrichtlinien sind zwar keine Sicherheitsfunktion an sich, doch können Administratoren mit ihrer Hilfe kontrollieren, wie Daten in einem Kubernetes-Cluster übertragen werden.

So können Sie zum Beispiel Netzwerkrichtlinien erstellen, um Pods auf der Netzwerkebene voneinander zu isolieren oder eingehenden Datenverkehr zu filtern.

Netzwerkrichtlinien stellen keinen Ersatz für den Schutz von Netzwerkkonfigurationen außerhalb von Kubernetes dar. Betrachten Sie sie lieber als zusätzliche Ressource, die die von Ihnen in die übergeordnete Netzwerkarchitektur integrierten Sicherheitsregeln ergänzen.

Kubernetes-Pod-Sicherheit

Ein Pod ist in Kubernetes ein Container oder ein Satz an Containern, der zur Ausführung einer Application verwendet wird. Zum Schutz Ihrer Applications müssen Sie darum Ihre Pods sichern.

Manche Aspekte von Pod-Sicherheit setzen Praktiken voraus, die nicht in Kubernetes ausgeführt werden. Vor der Bereitstellung einer Application sollten Sie diese einem Sicherheitstest unterziehen und Containerimages vor der Ausführung scannen. Zudem sollten Sie Logs aus Pods sammeln und analysieren, um mögliche Sicherheitsverletzungen oder missbräuchliche Nutzungen zu erkennen.

Kubernetes bietet jedoch einige native Tools, die die Pod-Sicherheit erhöhen können, nachdem Pods bereits ausgeführt werden. Dazu gehören:

  • RBAC-Richtlinien, die dazu dienen, den Zugriff auf Pods durch Benutzer und Services in einem Cluster zu verwalten.
  • Sicherheitskontexte, die über die Berechtigungsebene bestimmen, mit der Pods ausgeführt werden.
  • Netzwerkrichtlinien, die Sie (wie oben erwähnt) zur Isolation von Pods auf der Netzwerkebene nutzen können.
  • Zugangs-Controller, die zusätzliche Regeln durchsetzen können, um die mit RBAC definierten Regeln deutlich zu erweitern.

Die jeweiligen Pod-Sicherheitstools, die Sie verwenden, sowie die Weise ihrer Konfiguration hängen von der Art Ihrer Workloads ab. Es gibt keinen Standardansatz für Pod-Sicherheit. Manche Pods zum Beispiel lassen sich auf der Netzwerkebene komplett voneinander isolieren, während andere miteinander kommunizieren müssen.

Unabhängig von Ihren jeweiligen Anforderungen sollten Sie jedoch die Ressourcen evaluieren, die Ihnen zur Sicherung von Kubernetes-Pods zur Verfügung stehen, und dafür sorgen, dass Sie sie optimal nutzen.

Kubernetes-Datensicherheit

Kubernetes speichert keine Daten, mit Ausnahme nicht-persistenter Daten, die sich in ausgeführten Pods befinden, und auf Knoten gespeicherter Log-Daten. In der Regel werden Daten, die Ihre Cluster erzeugen und/oder aufrufen, in einer Art von externem Speichersystem gespeichert, das über ein Speicher-Plugin mit Kubernetes kommuniziert.

Um mit Kubernetes verbundene Daten zu schützen, sollten Sie also jene Best Practices befolgen, die Sie auch zum Sichern von Daten in einem beliebigen großen Speichersystem verwenden würden. Verschlüsseln Sie ruhende Daten soweit möglich. Verwenden Sie Zugangskontrolltools um einzuschränken, wer auf Daten zugreifen kann. Sorgen Sie dafür, dass die Server, die Ihre Speicherpools verwalten, richtig gesperrt sind. Erstellen Sie Sicherungskopien von Daten, um bei Datendiebstahl oder Ransomware-Angriffen geschützt zu sein.

Für die kleinen Mengen an Daten, die sich nativ in Kubernetes-Pods oder -Knoten befinden, bietet Kubernetes keine speziellen Sicherheitstools. Sie können sie jedoch schützen, indem Sie Ihre Pods und Knoten mit den oben beschriebenen Best Practices sichern.

Zusätzliche Kubernetes-Sicherheitsressourcen

Über die oben aufgeführten komponentenspezifischen Sicherheitspraktiken hinaus sollten Administratoren zusätzliche Sicherheitsressourcen für Kubernetes kennen.

Audit-Logs

Kubernetes kann optional granular aufzeichnen, welche Aktionen in einem Cluster von wem mit welchen Ergebnissen durchgeführt wurden. Mit diesen Audit-Logs können Sie Cluster umfassend prüfen, um mögliche Sicherheitsprobleme in Echtzeit zu erkennen sowie eingetretene Sicherheitsvorfälle zu analysieren.

Für die Verwendung von Audit-Logs müssen Sie zunächst eine Audit-Richtlinie erstellen, die definiert, wie Kubernetes Ereignisse erfassen soll. In der Kubernetes-Dokumentation finden Sie vollständige Details zur Einrichtung von Audit-Richtlinien.

Da Kubernetes keine Tools zur genauen Analyse von Audit-Logs bietet, sollten Sie Audit-Logs wahrscheinlich an externe Überwachungs- und Transparenzplattformen streamen. Diese können Ihnen dabei helfen, Anomalien zu erkennen, und Sie auf Sicherheitsverletzungen hinweisen. Alternativ lassen sich Audit-Ereignisse manuell überwachen, was in großem Maße jedoch nicht praktikabel ist.

Namespaces

Zur Isolation verschiedener Workloads untereinander können Sie in Kubernetes Namespaces verwenden.

Bei Bedarf können Sie zwar alles in einem Namespace ausführen, doch besteht die Best Practice aus einer Sicherheitsperspektive darin, für jedes Team und/oder für jede Art von Workload in Ihrem Cluster einen eigenen Namespace zu erstellen. So kann es sinnvoll sein, Ihre Dev/Test-Umgebung mithilfe separater Namespaces von der Produktion zu trennen.

Die Verwendung mehrerer Namespaces erhöht zwar leicht die administrative Komplexität von Kubernetes, da Sie oft (aber nicht immer) verschiedene RBAC-Richtlinien für die einzelnen Namespaces einrichten müssen. Der zusätzliche Aufwand lohnt sich jedoch, da die möglichen Auswirkungen einer Sicherheitsverletzung minimiert werden.

Einsatz externer Sicherheitstools mit Kubernetes

Kubernetes stellt zwar einige Tools bereit, mit denen sich Ressourcen, die in Ihrem Cluster ausgeführt werden, härten lassen, doch hilft Ihnen Kubernetes nicht bei der Erkennung oder Verwaltung von Sicherheitsvorfällen.

Für eine umfassende Verwaltung von Kubernetes-Sicherheit werden Sie wahrscheinlich auf externe Sicherheitstools zurückgreifen müssen. Solche Tools können verschiedene wichtige Sicherheitsaufgaben übernehmen. Sie können zum Beispiel:

  • Ihre RBAC-Richtlinien, Sicherheitskontexte und andere Konfigurationsdaten scannen, um fehlerhafte Konfigurationen zu erkennen, die Sicherheitsprobleme verursachen könnten.
  • Funktionen zum Scannen von Anwendungen und Containerimages bereitstellen, damit Sie eine automatische Sicherheitspipeline einrichten können, die in Ihre Kubernetes-Cluster hinein wirkt.
  • Application-Logs und Audit-Logs sammeln, aggregieren und analysieren, um Anomalien zu erkennen, die womöglich auf eine Sicherheitsverletzung hinweisen.

Es gibt verschiedene externe Sicherheitstools für Kubernetes. Ein Beispiel dafür ist natürlich Sysdig, das speziell entwickelt wurde, um DevOps-Teams dabei zu helfen, sämtliche Schichten von Kubernetes- und anderen cloudnativen Umgebungen zu schützen.