Ausnutzung von Schwachstellen
Sicherheit von Kubernetes Container Orchestration
Der Beitrag liefert Empfehlungen für Cloud-Administratoren, die eine Sicherheitsstrategie beim Einsatz von Kubernetes Container Orchestration festlegen müssen.
Originalartikel von Brandon Niemczyk, Cloud Security Research Lead
Kubernetes ist eines der in Cloud-Umgebungen am meist eingesetzten Container Orchestration-Systeme. Und wie jede weit verbreitete Anwendung stellt auch dieses System ein attraktives Ziel für Cyberkriminelle und andere Bedrohungsakteure dar. Der Beitrag liefert Empfehlungen für Cloud-Administratoren, die eine Sicherheitsstrategie beim Einsatz von Kubernetes Container Orchestration festlegen müssen.
Es gibt allgemein drei Bereiche, die Cloud-Administratoren sichern müssen, weil von dort aus Bedrohungen oder Risiken für die Kubernetes- Container-Strategie ausgehen können:
- Externe Angriffe: also Angriffe von außerhalb der Organisation (jeder nicht authentifizierte Zugriff gehört dazu)
- Probleme durch Fehlkonfigurationen
- Angreifbare Anwendungen: Gefahren infolge von Schwachstellen in der Software oder in Anwendungen
Externe Angriffe
Das Bild zeigt die Komponenten einer Kubernetes-Installation oder eines Clusters, wie sie in der offiziellen Dokumentation von Kubernetes dargestellt wird.
Die gesamte Kommunikation läuft über kube-api-server, eine Komponente der Kontrollebene, die die Anwendungsprogrammierschnittstelle (API) exponiert. Es geht im Grunde genommen um eine Representational State Transfer (REST) API, das als Frontend für die Steuerungsebene fungiert und über das Nutzer alle Kubernetes Managementfunktionen definieren und kontrollieren können. Der einfachste Weg, die API zu verwenden, führt über das Befehlszeilenkommando kubectl (oder oc für OpenShift).
Angreifer, denen es gelingt, auf die API zuzugreifen, können praktisch jedes erdenkliche Ziel verwirklichen. Sie können etwa bösartige Container installieren, um Informationen aus Datenbanken zu ziehen oder um Ressourcen für Krypto-Mining abzuzweigen.
Daher ist es von hoher Bedeutung sicherzustellen, dass diese API lediglich von den Maschinen in einem Cluster zu erreichen ist, die Administrationsaufgaben erfüllen müssen. Cloud-Administratoren sollten bedenken, dass kube-api-server standardmäßig an zwei Ports horcht:
Hier geht es um höhere Sicherheit, um Eindringlinge abzuhalten.
Empfehlungen für den Schutz von Clustern gegen externe Angriffe:
- Aufstellen einer Firewall-Regel, um sicherzustellen, dass nur die Maschinen auf die API zugreifen können, die das auch tun müssen.
- Vermeiden des Einsatzes der insecure-bind-address-Option zum Öffnen des Klartext-Ports außerhalb des localhost.
- Einsatz von Intrusion Prevention Systems (IPSs) mit Secure Sockets Layer (SSL)-Entschlüsselungsfähigkeiten, so z.B. Trend Micro™ TippingPoint™ Threat Protection System, das Monitoring des Verkehrs zu und von der API erlaubt.
Probleme durch Fehlkonfigurationen
Kubernetes bietet eine hohe Flexibilität dank der vielen Konfigurationsoptionen. Doch sollten Anwender diese richtig verstehen und sicher aufsetzen, um die Gefahr der Kompromittierung eines Clusters zu vermeiden.
Selbst die Authentifizierungskonfiguration allein ist bereits sehr komplex, da es mehrere Arten der Authentifizierung gibt (rollen-, attribut- oder knotenbasiert). Als Hilfe können Cloud-Administratoren den Befehl kubectl auth can-i verwenden, um bestimmte Berechtigungen abzufragen. Kubernetes Benutzer- und Service-Konten sollten lediglich die Berechtigungen erhalten, die sie tatsächlich benötigen.
Dieser Konfigurationsaspekt ist besonders wichtig, warnen die Sicherheitsforscher, denn sie haben bereits eine ganze Reihe von fehlkonfigurierten Instanzen gefunden. So zeigt ein schneller Shodan-Scan, dass es weltweit nahezu 3.000 Hosts gibt, wo etcd, ein Schlüsselwert-Server bei Kubernetes, öffentlich zugänglich ist.
Des Weiteren müssen Cloud-Administratoren im Hinterkopf behalten, dass es keine Netzwerk-Policy für einen bestimmten Namensraum gibt, und die standardmäßige Policy erlaubt den Verkehr hin und von allen Pods in dem Namensraum.
Jeder Pod kann mit jedem anderen Pod kommunizieren. Wenn ein Angreifer also in einen öffentlich zugänglichen Pod eindringen kann (z.B. mit einer Webanwendung), dann kann er diesen nutzen, um sich mit anderen Pods zu verbinden. Dies erleichtert Angreifern die laterale Bewegung nach dem Eindringen erheblich.
Best Practice hier besteht darin, den Zugang standardmäßig zu verbieten und Verkehr nur explizit zuzulassen. Es sollte zumindest eine standardmäßige Policy vorhanden sein, die den eingehenden Verkehr verbietet. Eine solche Policy lässt sich über den spezifischen Code in Kubernetes offizieller Dokumentation implementieren.
Empfehlungen für den Schutz von Cluster gegen Fehlkonfigurations-Probleme
- Durchführen eines gründlichen Audits aller Kubernetes Nutzer- und Service-Konten, um sicherzustellen, dass lediglich der Zugang für benötigte Aktionen erlaubt ist. Es sollten auch regelmäßige Überprüfungen stattfinden, um zu checken, ob die Policies auch weiterhin in Kraft sind.
- Wenn möglich, eine Kubernetes-Distribution einsetzen, die unter Umständen nur limitierte Wahlmöglichkeiten bietet aber in gewissem Maße eine sichere Out-of-Box-Konfiguration mitbringt, so etwa RedHat OpenShift.
- Den Leitfaden des Cloud Providers nach bestimmten Anleitungen durchsuchen. Die meisten Provider haben einen solchen. Prüfen der CIS Kubernetes Benchmark vom Center for Internet Security.
- Sicherstellen, dass alle von Kubernetes genutzten Services hinter einer geeigneten Firewall stehen und nicht öffentlich exponiert sind.
- Die Netzwerk-Policies sollten ankommenden Verkehr standardmäßig nicht zulassen.
Angreifbare Anwendungen
Wie auch im Fall von regulären Servern und Betriebssystemen ist ein Kubernetes-Cluster nur so sicher wie der am schwächsten gesicherte Service, der darauf läuft. Container und Container Orchestratoren erleichtern nicht nur den Betrieb einer Vielfalt von Anwendungen in einer heterogenen Umgebung, sondern auch die kombinierte Nutzung von Apps in vielen Variationen. Doch sie lösen nicht alle Fragen. Tatsächlich kann die Art der Container es sogar noch erschweren sicherzustellen, dass die Updates überall dort angewendet werden, wo sie benötigt werden, da jede Anwendung ihre eigene Kopie jeder Bibliothek hat.
Dieselbe Bibliothek kann in mehreren Images aus verschiedenen Basis-Images installiert werden. Und diese müssen alle aktualisiert und mit Sicherheits-Patches versehen werden. Die Integration einer Lösung wie Trend Micro Deep Security™ Smart Check in den DevOps-Prozess kann in dieser Hinsicht hilfreich sein.
Empfehlungen für den Schutz von Cluster gegen angreifbare Anwendungen
- Zumindest sicherstellen, dass alle genutzten Container Images aktualisiert werden und aus vertrauenswürdigen Quellen stammen.
- Einsetzen von Container-spezifischen, automatisierten Scanning-Technologien wie etwa die in Trend Micro™ Deep Security™ Smart Check – Container Image Security, um Images für Apps zu scannen als Teil des kontinuierlichen Integrations- und Delivery (CI/CD)-Prozesses.
Sichern von Clustern mit Cloud-spezifischem Schutz
Cloud-spezifische Sicherheitslösungen wie Trend Micro™ Hybrid Cloud Security und Trend Micro Cloud One™ können den Schutz in diesen Instanzen verschlanken.
Hybrid Cloud Security liefert Threat Defense, um physische, virtuelle und Cloud-Workloads sowie Container während der Laufzeit zu schützen. Auch scannt die Lösung Container Images während der Entwicklungsphasen.
Cloud One, eine Sicherheits-Serviceplattform für Cloud-Entwickler, liefert automatisierten Schutz für die CI/CD-Pipeline und Anwendungen. Sie unterstützt Unternehmen auch dabei, Sicherheitsprobleme schneller zu erkennen und zu lösen, und verkürzt die Bereitstellungszeitspanne für DevOps-Teams. Die Lösung umfasst:
- Workload Security: Laufzeitschutz für Workloads (in virtuellen, physischen, Cloud- und Container-Umgebungen)
- Container Security: automatisiertes Scanning der Container Image und Registry
- File Storage Security: Sicherheit für Cloud-Services für die Speicherung von Dateien und Objekten
- Network Security: IPS-Schutz für Cloud-Netzwerkebenen
- Application Security: Sicherheit für serverlose Funktionen, APIs und Anwendungen