Wie sicher ist Kubernetes? – CIS Benchmark und Kubernetes Hardening Guides im Vergleich

Laut der aktuellsten Umfrage der Cloud Native Computing Foundation (CNCF) ist der Einsatz von Containern in Produktivumgebungen seit 2016 um außerordentliche 300 % gestiegen. Bei der Wahl des richtigen Container Orchestrators ist man sich einig – Kubernetes hat sich als De-factor-Standard etabliert.

Leider ist der Aufbau einer sicheren Kubernetes Umgebung nicht ganz trivial und hält bei der Konfiguration einige Fallstricke bereit. Das Center for Internet Security (CIS) veröffentlicht seit 2017 die CIS Benchmarks, bestehend aus einer Reihe von Konfigurationsempfehlungen für Kubernetes, die dabei helfen sollen, ein höheres Sicherheitsniveau zu erreichen. Ein ähnliches Ziel verfolgen NSA und CISA mit dem Kubernetes Hardening Guide, welcher dieses Jahr erstmals veröffentlicht wurde. Beide Guides unterscheiden sich in der Umsetzung und deutlich im Umfang. Eine Gegenüberstellung soll zeigen, wo die Unterschiede liegen und ob die wichtigsten Sicherheitsaspekte abgedeckt werden.

Pod und Image Scans

Das Scannen von Container Images auf bekannte Vulnerabilities ist eigentlich ein Best Practice im Container Security Umfeld, wird aber nur von 44 % der Developer befolgt. Das Problem dabei ist, dass Pods und Images keine automatischen Updates erhalten, wenn neue Vulnerabilities bekannt werden. Images und Pods sollten deshalb regelmäßig auf Vulnerabilities gescannt werden. Oft werden Images aber nur initial beim Push in die Registry gescannt. Je stabiler eine Applikation läuft, desto seltener wird sie upgedatet und desto seltener wird dementsprechend auch ein Scan durchgeführt.

NSA/CISA:

Es wird die Nutzung eines Kubernetes Admission Controllers empfohlen. Dabei handelt es sich um eine Kubernetis native Komponente, die API Requests abhören und verarbeiten kann. Somit kann vor der Erstellung eines Pods ein Vulnerability Scan Request angefordert werden. Je nachdem wie das Ergebnis ausfällt, kann darauf reagiert werden, noch bevor das Objekt tatsächlich existiert.

CIS:

Hier wird ebenfalls die Verwendung eines Kubernetes Admission Controllers genannt, um Image Policies im Cluster durchzusetzen. Es wird empfohlen Regeln so zu konfigurieren, dass nur freigegebene Images im Cluster zur Ausführung kommen können. Images müssen regelmäßig geprüft werden, wenn diese Updates erhalten.

Bewertung:

Das große Problem bleibt bestehen. Ein Scan wird so zwar bei jedem neuen Deployment und bei jedem Update durchgeführt, wird eine Applikation allerdings lange Zeit nicht upgedatet, weil sie beispielsweise sehr stabil läuft, dann gibt es keine weiteren Scans. Es sollte deshalb ein Prozess etabliert werden, der das regelmäßige Scannen von Pods und Images im Kubernetes Cluster sicherstellt.

Rechte von Containern und Pods

Einige der populärsten Images, die auf DockerHub zu finden sind, werden in Containern standardmäßig mit dem „root“-User ausgeführt. Tatsächlich werden „Containerized Applications“ von Kubernetes kaum in ihren Aktionen eingeschränkt. Dementsprechend schwerwiegend ist die erfolgreiche Kompromittierung eines Pods bzw. Containers in einem Kubernetes Cluster, da der Angreifer dann mit entsprechend vielen Rechten im Cluster ausgestattet ist.

NSA/CISA:

• Container sollten nicht als „root“-User laufen, um die Rechte eines potenziellen Angreifers einzuschränken, falls dieser Zugriff auf einen Pod bzw. Container erlangen sollte. Mit entsprechender Konfiguration erlauben es Container Engines den Containern auch, Anwendungen als „non-root“-User auszuführen. Weiterhin gibt es auch die Möglichkeit eine „Rootless Container Engines“ zu nutzen. Zum aktuellen Zeitpunkt haben diese jedoch noch experimentellen Status.

• Container Dateisysteme sollten unveränderbar sein, damit beispielsweise ein Angreifer nach der erfolgreichen Kompromittierung eines Containers seine Spuren nicht verwischen kann. Ohne entsprechende Konfiguration kann ein Angreifer innerhalb eines Containers außerdem Dateien erstellen, Skripte downloaden und generell die Applikation im Container verändern. Kubernetes kann dieses Verhalten einschränken.

• Es sollte eine möglichst restriktive Pod Security Policy (PSP) genutzt werden, um beispielsweise die Verwendung eines „non-root“-Users zu erzwingen. Eine PSP ist eine cluster-weite Policy, die eine bestimmte Basis an Sicherheitsanforderungen vorgibt, denen alle Pods entsprechen müssen, die im Cluster zum Laufen gebracht werden sollen. Die Durchsetzung von PSPs erfolgt durch einen Kubernetes Admission Controller, dementsprechend sind diese nur bei der Erstellung eines Pods wirksam und können keine bereits laufenden Pods beeinflussen.

• Default Service Account Tokens sollten Pods im Cluster nicht unnötigerweise zur Verfügung gestellt werden, um einen Missbrauch der API zu minimieren. Standardmäßig wird von Kubernetes automatisch ein Service Account (SA) bereitgestellt, wenn ein Pod erstellt wird. Der Secret Token des SA wird dann zur Laufzeit in den Pod gemountet. Die meisten „Containerized Application“ benötigen aber nicht einmal direkten Zugriff auf den Service Account. In Kubernetes können Pods vor der Erstellung so konfiguriert werden, dass dieser SA Token nicht automatisch gemountet wird.

CIS:

• Wenn ein Pod Zugriff auf die Kubernetes API benötigt, dann soll genau für diesen Zweck ein Service Account mit entsprechenden Rechten erstellt und der Token dem Pod zur Verfügung gestellt werden. Der default Service Account sollte so wenige Rechte wie möglich besitzen und so konfiguriert sein, dass dieser nicht automatisch einen Service Account Token bereitstellt.

• Sogenannte Privileged Containers haben Zugriff auf alle Linux Kernel Capabilities und können fast alles tun, was auch der Host kann. Grundsätzlich sollte die Ausführung von Privileged Container z. B. durch eine Policy verboten werden.

• Die Ausführung von Containern im Host PID Namespace, Host IPC Namespace oder Host Network Namespace sollte durch einen Policy verboten werden. Solche Container haben Einsicht in alle laufenden Prozesse auf dem Host (PID Namespace), können mit Prozessen außerhalb des Containers kommunizieren (IPC Namespace) und auf den Netzwerkverkehr anderer Pods zugreifen (Network Namespace).

• Container mit dem „AllowPrivilegeEscalation“ String erlauben es Prozessen mehr Rechte zu bekommen, als ihr Parent Prozess. Es sollte eine Policy existieren, welche die Ausführung solcher Container verhindert.

• Es sollte eine Policy vorhanden sein, die Container verbietet als „root“-User zu laufen.

• Container sollten nicht mit der NET_RAW Capability ausgeführt werden, weil dadurch ein potenzieller Angreifer diverse Netzwerk Exploits vom Cluster aus durchführen kann. Es wird eine Policy empfohlen, um dies zu verhindern.

• Container Runtimes weisen den Containern bei der Ausführung einige Standard Capabilities zu. Es ist möglich den Containern weitere Capabilities hinzuzufügen, generell sollte dies aber mit einer entsprechenden Policy verhindert werden.

Netzwerksegmentierung

Grundsätzlich dürfen Pods innerhalb eines Kubernetes Clusters ohne Einschränkungen untereinander kommunizieren, egal ob sich diese im gleichen oder in verschiedenen Namespaces befinden. In der Theorie ist das gesamte Cluster nur so sicher wie das schwächste Glied in der Kette. Erhält ein Angreifer Zugriff auf den am wenigsten sicheren Pod, dann hat er im Grunde Zugriff auf alle Pods des Clusters.

NSA/CISA:

Die Kommunikation einzelner Komponenten im Cluster untereinander sollte mit Hilfe von Kubernetes Netzwerk Policies geregelt und einschränkt werden. Damit kann beispielsweise sichergestellt werden, dass das Frontend nur mit dem Backend respektive eine Datenbank nur mit dem Backend kommunizieren darf. Wichtig ist, dass das in Kubernetes eingesetzte Netzwerk Plugin die Nutzung von Netzwerk Policies unterstützt.

CIS:

Netzwerk Segmentierung ist wichtig, um sicherzustellen, dass nur Container miteinander kommunizieren können, die dies tatsächlich auch tun sollen. Dies soll mit Hilfe von Netzwerk Policies sichergestellt werden, die in Kubernetes vom Netzwerk Plugin durchgesetzt werden. Aus diesem Grund ist es wichtig ein Netzwerk Plugin einzusetzen, welches sowohl Ingress als auch Egress Netzwerk Policies unterstützt. Es sollten für alle Namespaces des Clusters Netzwerk Policies definiert werden, um unerlaubten Datenverkehr zu blockieren. Ebenso muss gewährleistet sein, dass zulässiger Datenverkehr erlaubt ist.

Firewalls und Verschlüsselung

Ein Kubernetes Cluster besteht aus einer oder mehreren Control Plane(s) und Worker Node(s). Auf der bzw. den Control Plane(s) befinden sich Komponenten, die für die Steuerung des gesamten Clusters verantwortlich sind. Wenn ein Angreifer Zugriff auf die Control Plane erlangt, kann er folglich das gesamte Cluster kontrollieren.

NSA/CISA:

• Eine Firewall kann helfen die Control Plane(s) zu härten und gegen externe Angriffe abzusichern. Je nach Anforderungen sollten die Komponenten auf der Control Plane nur so weit wie absolut nötig nach außen zugänglich gemacht werden.

• Innerhalb des Kubernetes Clusters wird der Netzwerkverkehr standardmäßig unverschlüsselt übermittelt, was einen weiteren potenziellen Angriffsvektor darstellt. Dieses Problem lässt sich vergleichsweise leicht durch ein Kubernetes Network Plugin mit einer entsprechenden Verschlüsselungsoption realisieren.

• Sensitive Informationen wie Passwörter oder SSH Keys werden in Kubernetes in Secrets gespeichert. Standardmäßig werden die Daten in base64 codiert, bleiben jedoch unverschlüsselt und können somit von jedem mit API Zugriff ausgelesen werden. Es gibt einige Third-Party Lösungen, die hierfür sinnvoll genutzt werden können.

CIS:

Da Secrets sensitive Informationen enthalten und grundsätzlich keine Verschlüsselung besitzen, wird ein externes Secret Storage und Management System empfohlen.

Authentifizierung und Autorisierung

Mechanismen zur Authentifizierung und Autorisierung helfen dabei den Zugriff auf Cluster Ressourcen zu steuern. Die Authentifizierung von Nutzern ist kein Feature, das in Kubernetes standardmäßig zur Verfügung steht, es gibt allerdings verschiedene Möglichkeiten, um ein Cluster um diese Funktionalität zu erweitern.

NSA/CISA:

• Für normale User- und Admin-Accounts gibt es in Kubernetes kein Feature zur Authentifizierung. Es wird davon ausgegangen, dass User cluster-unabhängig verwaltet werden. Um die Authentifizierung und Autorisierung im Cluster gewährleisten zu können, müssen entsprechende Methoden implementiert werden.

• In einer Konfiguration mit aktivierten Anonymous Requests werden alle Requests, die nicht von einer anderen Authentifizierungsmethode geblockt werden, als Anonymous Requests ausgeführt. Werden in einem so konfigurierten Cluster beispielsweise Tokens zur Authentifizierung verwendet, dann würde auf einen Request mit ungültigem Token ein „Unauthorized“-Error folgen. Ein Request ohne Token wird aber als Anonymous Request behandelt und akzeptiert. Anonymous Requests sind seit Kubernetes v1.6 standardmäßig aktiviert und sollten deaktiviert werden.

• Durch Role Based Access Control (RBAC) kann gesteuert werden, wer auf welche Cluster Ressource zugreifen darf. Es sollte geprüft werden, ob RBAC aktiviert ist, standardmäßig müsste dies jedoch so sein.

• Berechtigungen werden im Zusammenhang mit RBAC über Roles bzw. ClusterRoles vergeben, die je nachdem nur für einen bestimmten Namespace bzw. cluster-weit gelten. Diese werden dann an User, Gruppen oder Service Accounts gebunden. Es sollte darauf geachtet werden, dass Roles und ClusterRoles nur so viele Rechte besitzen, wie für die Ausführung einer Aufgabe auch benötigt werden.

CIS:

• Kubernetes hält einige Standard Rollen für die RBAC Nutzung bereit. Darunter befindet sich auch die Cluster-Admin Rolle, welche Super-User Rechte besitzt, mit denen so ziemlich jede Aktion durchgeführt werden kann. Zugriff auf diese Rolle sollte streng überwacht und limitiert werden.

• Secrets enthalten sensible Daten, deshalb sollte der Zugriff darauf streng überwacht und auf die kleinstmögliche Gruppe an Nutzern eingeschränkt werden.

• Roles und ClusterRoles definieren Berechtigungen für den Zugriff auf Ressourcen im Cluster und welche Aktionen in diesem Zusammenhang ausgeführt werden dürfen. Es sollte darauf verzichtet werden für Aktionen oder Ressourcen die Wildcard „*“ zu verwenden, da diese stellvertretend für alle möglichen Optionen steht. Roles und ClusterRoles sollten nur so viele Rechte besitzen, wie für die Ausführung einer Aufgabe auch benötigt werden.

• Die Erstellung von Pods kann missbräuchlich zur Rechteausweitung im Cluster genutzt werden. Nur eine kleinstmögliche Gruppe an Nutzern sollte die Berechtigung besitzen Pods erstellen zu können.

Log Auditing

Aktionen, die im Cluster durchgeführt werden, können mit Hilfe von Audit Logs protokolliert werden. Das ist wichtig, um die Sicherheit in Kubernetes gewährleisten zu können. Zusätzlich kann damit die Nutzung von CPU und Speicher Ressourcen im Cluster überwacht werden.

NSA/CISA:

In der Standardkonfiguration ist das Audit Logging in Kubernetes nicht aktiv und sollte eingeschaltet werden. Außerdem wird empfohlen Logging auf Host Level, Application Level und wenn zutreffend auf Cloud Level durchzuführen, um ein Gesamtbild der Umgebung zu erhalten. Es wird weiterhin empfohlen Kubernetes Logs per Webhook an eine SIEM Plattform zu senden, um diese effektiv auswerten und weiterverarbeiten zu können.

CIS:

Logging ist wichtig, um potenziell unautorisierte Zugriffe feststellen zu können, dementsprechend wird empfohlen dieses per Konfiguration zu aktivieren. Es sollte außerdem die Speichernutzung der Audit Logs beobachtet werden, da diese sehr schnell eine große Menge an Speicherplatz einnehmen können.

Updateverhalten

Ungefähr dreimal im Jahr erscheint eine neue Kubernetes Version. Nur die aktuellste Version sowie die beiden vorherigen Versionen werden mit Sicherheitsupdates versorgt.

NSA/CISA:

Sicherheit ist ein fortlaufender Prozess, deshalb ist es wichtig alle Komponenten mit Patches, Updates und Upgrades zu versorgen und auf einem aktuellen Stand zu halten.

CIS:

Im CIS Benchmark werden dazu keine Empfehlungen angegeben.

Schlussgedanke

Darüber hinaus gibt der CIS Benchmark einige weitere Empfehlungen an, was die Konfiguration von Kubernetes betrifft, die so im Detail im Kubernetes Hardening Guide nicht zu finden sind. Daraus ergibt sich dann auch der sehr große Unterschied im Umfang der beiden Guides (CIS: 59 Seiten; NSA/CISA: 299 Seiten). Wen die weiteren Punkte interessieren, der kann natürlich selbst einen Blick in den aktuellen CIS Benchmark werfen, für alle anderen stellt Aqua Security eine kurze Zusammenfassung bereit.

Um wieder auf die Einstiegsfrage zurückzukommen, wie sicher Kubernetes ist – es ist nicht sicher genug! Jedenfalls ist das so, wenn man sich nicht weiter mit der Konfiguration befasst.

Der Kubernetes Hardening Guide von NSA und CISA spricht viele Punkte an, die beachtet werden sollten, um Kubernetes sicherer zu machen. Die großen Themen finden sich in beiden Guides wieder, dennoch ist der CIS Benchmark etwas ausführlicher und detaillierter. Der Guide von NSA und CISA enthält aber auch ein paar Aspekte, die so im CIS Benchmark noch nicht zu finden waren. Aus meiner Sicht macht es keinen Sinn sich nur auf die Informationen aus dem einen oder dem anderen zu verlassen. Sowohl CIS Benchmark als auch Kubernetes Hardening Guide stellen eine wertvolle Ressource dar, um die Sicherheit im Kubernetes Umfeld gewährleisten zu können.