© DifferR/Shutterstock.com, © Nikolayev Alexey/Shutterstock.com
Ein Leitfaden zur Absicherung von Containernetzwerken

Kubernetes-Security


Kubernetes ist nicht mehr wegzudenken und genießt einen hohen Stellenwert bei Endnutzern und Public-Cloud-Providern. Der Trend zum eigenen Kubernetes-Cluster bleibt auch von Angreifern nicht unbemerkt. Die Vielschichtigkeit der Technologie, angefangen vom Design der laufenden Applikationen über Container hin zur Clusterarchitektur, erlaubt eine Menge neuer Angriffsvektoren und Potenziale für Fehlkonfigurationen.

Dank der verfügbaren Funktionalitäten und der Verschiebung weg von monolithischen hin zu flexibleren Microservices-Architekturen hat die Containerorchestrierungsplattform Kubernetes einen hohen Stellenwert am Markt erlangt. Viele Organisationen nutzen daher Kubernetes oder eine darauf aufbauende Lösung wie Red Hat OpenShift oder Rancher bereits produktiv. Meist jedoch ohne die dafür notwenigen Securitymaßnahmen zu etablieren oder eine Strategie zu haben. Ein Verhalten, das auch für Hacker nicht ungesehen bleibt.

Der wohl bekannteste Angriff auf Kubernetes ist der Cryptojacking Hack auf Tesla (veröffentlicht im Februar 2018), in dem Angreifer über die ungesicherte Kubernetes-Administrationskonsole auf die Umgebung zugriffen und mit Hilfe von versteckten containerisierten Crypto-Mining Services die Systemressourcen der unterliegenden Amazon-Instanzen für das Mining von Kryptowährungen missbrauchten [1]. Der Angriff wurde so gut versteckt, dass er erst von Personen außerhalb der Organisation, durch Analysten des Red-Lock-Cloud-Security-Intelligence-Teams, aufgedeckt wurde. Nach Angaben von Red Lock wurde das Team während einer Studie über Bedrohungen auf Public-Cloud-Umgebungen auf den Vorfall aufmerksam. Red Lock entdeckte hierbei eine Vielzahl von ungeschützten Administrationskonsolen, die neben Tesla auch Aviva und Gemalto betrafen.

Während diese Vorfälle bereits durch grundlegende Security-Best-Practices vermieden werden können, müssen Kubernetes-Anwender ihre Umgebungen auch regelmäßig gegen neue Schwachstellen wie z. B. ungewollte Zugriffe auf das Backend über den kube-API-Server (CVE-2018-1002105) oder Privilege Escalations durch das PodSecurityPolicy-Admission-Plug-in (CVE-2017-1000056) absichern. Die Absicherung von Kubernetes-Umgebungen ist oftmals ein schwieriges Unterfangen, das sowohl mit der komplexen Systemarchitektur als auch der Arbeitsweise im Umgang mit der Entwicklung, Auslieferung und dem Betrieb von Microservices zusammenhängt.

Der Grundstein für sichere Kubernetes-Umgebungen

Die Unternehmens- und Teamkultur stellt im Hinblick auf die Absicherung von Kubernetes-Clustern eine der größten Herausforderungen dar. Sie spielt eine elementare Rolle im Umgang mit Microservices und entscheidet häufig darüber, wie schnell neue Anwendungen bereitgestellt werden und wer für deren Sicherheit verantwortlich ist und diese umsetzt. In traditionellen Softwareentwicklungslebenszyklen orientiert sich die Auslieferung von Anwendungen an großen Softwarepaketen oder gar gesamten monolithischen Applikationen, die vor Produktivgang Stages für fachliche, technische und sicherheitsbezogene Tests durchlaufen müssen. Dieses Vorgehen ist zumindest aus einer zeitlichen Perspektive oftmals ein langwieriger Vorgang aufgrund der Abnahmeprüfungen und Nachbesserungszyklen.

Mit dem Eintritt in die Welt der Microservices verkürzt sich die Dauer zur Erstellung auslieferungsfähiger Softwarepakete, was dazu führt, dass kürzere Releasezyklen notwendig sind. Daher ist es wenig überraschend, dass sich Teams im Umgang mit Containern und Kubernetes-Umgebungen zunehmend den Themen Automatisierung, Continous Integration und Continous Deployment widmen müssen bzw. sollten. Die Containerisierung von Softwareapplikationen deckt zudem auch große Teile des Applikationsbetriebs ab, wodurch die Grenzen zwischen Entwicklung und Betrieb weiter verschwimmen. Aus diesen Gründen ist es nicht überraschend, dass Teams im Umgang mit Kubernetes-Netzwerken auf DevOps-Vorgehensmodelle zurückgreifen.

DevOps ist ein mittlerweile weit verbreiteter Begriff, der bis heute nicht klar definiert ist. Wir fassen unter den Begriff DevOps einen philosophischen Ansatz für Zusammenarbeitsmodelle zwischen den Domänen Development und Operations zusammen. DevOps setzt sich zum Ziel, die Delivery-Qualität und Geschwindigkeit durch die Automatisierung der einzelnen Entwicklungs- und Deployment-Schritte und durch Konfigurationsmanagement zu erhöhen. Das Zusammenspiel aus DevOps und Kubernetes ergänzt sich dabei entscheidend, da Container als integraler Bestandteil automatisierter Software-Builds und der kontinuierlichen Integration und Bereitstellung dienen. Die hohe Geschwindigkeit stellt viele Organisationen aber auch vor eine große Herausforderung. Insbesondere, wenn nicht die gesamte Unternehmung einen DevOps-Ansatz verfolgt. In diesem Fall stehen die interdisziplinären Teams einer klassischen siloartigen Trennung von Anwendungsentwicklungs-, Betriebs- und Securityabteilungen gegenüber. Die klassische Trennung in feste Aufgaben und Verantwortlichkeiten macht sich besonders auf der Securityseite bemerkbar. IT-Security-Abteilungen verstehen sich zumeist erst ab dem Beginn des internen Netzwerks mit dem Switch für die Absicherung gegen IT-Angriffe verantwortlich. Diese Trennung stellt für Microservices-Umgebungen ein großes Risiko dar, da die Kommunikation auf Containerebene nicht mehr nur über die Netzwerk- und Transportschichten (Layer 3 und 4 im OSI-Modell), sondern auf der Applikationsebene (Layer 7) erfolgt und etablierte Securitygateways dort keine Sichtbarkeit erzeugen. Klassische Securitytests, die aus der Entwicklung von Softwaremonolithen bekannt sind, lassen sich nur schwer auf Kubernetes-Cluster abbilden. Containerapplikationen sind zu kurzlebig und ändern den Zustand der Betriebsumgebung viel schneller als die Testergebnisse zurückgespielt werden können.

Um ihre produktiven Systeme dennoch gegen Angriffe und Schwachstellen zu schützen, legen DevOps-Teams daher oft selbst Hand an. Den Teams fehlt es aber oft an der notwendigen Erfahrung und Reife im Gesamtkontext der bestehenden Sicherheitsarchitektur ihrer Organisationen, wodurch sich schnell Lücken in der IT-Sicherheit, damit verbundenen Reportingpflichten und auch dem Response-Management in akuten Sicherheitsvorfällen ergeben. Aus diesen Gründen besteht die Notwendigkeit, die IT-Security in aktiver Form in die DevOps-Teams zu integrieren.

Inhaltliche Befähigung der IT-Security durch Awareness-Programme

Da sich das Aufgabenmodell der Security in DevOps-Organisationen weg vom klassischen Prüf-Test-Patch-Mindset und hin zur proaktiven Absicherung der Systeme noch während der Entwicklung und Auslieferung verändert, durchlaufen IT-Security-Einheiten oft einen kulturellen Wandel. Dieser Wandel lässt sich besonders unterstützen, wenn die bestehenden DevOps-Teams ihren Organisationen einen aktiven Einblick in ihre Arbeitsweisen verschaffen. Ein erster Schritt sind der Aufbau und die Nutzung von Austauschplattformen. So können bereits Blogposts auf der organisationseigenen Plattform dazu dienen, Mitarbeiter aus anderen Verantwortungsbereichen auf die hauseigenen Kubernetes-Umgebungen und CI/CD-Prozesse aufmerksam zu machen. Besonders unterstützend sind aber auch der Kanal der persönlichen Ansprache und die aktive Einladung der Securityexperten zu internen Vorstellungen z. B. in Lightning oder Tech-Talks. In beiden Fällen sollten die jeweiligen IT-Security-Experten die Chance bekommen, ein erstes Verständnis für die neuen Technologien und Arbeitsweisen zu entwickeln.

Im nächsten Schritt sollte auch die Einbeziehung der IT-Security-Experten in siloübergreifenden Communities in Betracht gezogen werden. Mit Hilfe von Slack- oder Mattermost-Channels erlauben diese Kanäle den DevOps-Teams nicht nur den toolgestützten teamübergreifenden Austausch, sondern auch den Einbezug der IT-Security-Experten in offene Diskussionen.

Organisatorische Aufstellung und Zusammenarbeitsmodell

Während die inhaltliche Einbeziehung de...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang