Kubernetes unter Beschuss

Kubernetes Security: Ein Leitfaden zur Absicherung von Containernetzwerken

Maximilian Siegert, Patrice Volkmer

© Shutterstock / Nikolayev Alexey

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. 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 Silo-artigen 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. Klassischen 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 der IT-Security-Experten auf Initiative der DevOps-Teams erfolgen kann, ist die Transformation des Zusammenarbeitsmodells abhängig von den Vorgaben des Managements. Wir bei NTT DATA nutzen z. B. bei der Diskussion von Zusammenarbeitsmodellen gerne DevSecOps-Topologien, die wir an die DevOps-Topologien von Matthew Skelton und Manuel Pais angelehnt haben. Die typischsten vier Topologien, die die Autoren bei Organisationen erkennen, finden Sie in Abbildung 1.

Abb. 1: Zusammenarbeitsmodelle zwischen IT-Security und DevOps-Teams

Abb. 1: Zusammenarbeitsmodelle zwischen IT-Security und DevOps-Teams

Diese vier Zusammenarbeitsmodelle aus Abbildung 1 lassen sich folgendermaßen definieren:

  1. Entscheidet sich eine Organisation dafür, dass die Verantwortungsträgerschaft zur Absicherung der DevOps-Umgebung in den DevOps-Teams verbleibt und die IT-Security nicht zu integrieren ist, besteht eine feste Trennung. Dies führt dazu, dass die DevOps-Teams ihre eigenen Securityfähigkeiten erlernen müssen. In dieser Lernperiode ist zu erwarten, dass die Umgebungen anfällig für Sicherheitsvorfälle sind und die Teams ohne Begleitung in Gefahr laufen, relevante Sicherheitsaspekte zu ignorieren. Das Szenario stellt daher eher einen Antitypen dar.
  2. Trifft die Organisation die Entscheidung, dass die Verantwortungsträgerschaft zu teilen oder vollständig an die IT-Security-Abteilung übergeht, können drei Topologien entstehen:
  1. DevOps-Teams und IT-Security verbleiben getrennt. Die Absicherung der Umgebung erfolgt zu Teilen oder vollständig durch Prüfinstanzen während der Softwareauslieferung. Auch dieses Szenario stellt zunächst einen Antityp dar, da sich die IT-Security lediglich als Kontrollfunktion integriert und so sogar im schlimmsten Fall die Auslieferungsgeschwindigkeit der DevOps-Teams ausbremst.
  2. Die IT-Security-Einheiten werden vollständig in die DevOps-Teams integriert. Die Teams verantworten die vollständige Absicherung des Entwicklungs- und Integrationsprozesses (Full-DevSecOps-Teams). Eine volle Integration der IT-Security-Ressourcen in den DevOps-Teams ist häufig in jungen Organisationen auffindbar und erlaubt den einzelnen Teams eine aktive Absicherung von der Entwicklung bis hin zum Betrieb. Ein dezentralisierter Ansatz sollte stets durch eine übergreifende Community begleitet werden, um Knowledge Sharing zwischen den Teams zu etablieren und redundante Lösungen zu vermeiden.
  3. Die IT-Security-Einheiten beteiligen sich aktiv mit Ressourcen an der Absicherung des Entwicklungs- und Integrationsprozesses und verbleiben gleichzeitig als eigenständige Einheit (hybrides Modell). Das Hybridszenario verbindet die Vorteile aus beiden Welten, da eine zentrale IT-Security-Anlaufstelle existiert und gleichzeitig IT-Security-Ressourcen den DevOps-Teams zugeordnet werden. Die zu den Teams zugeordneten Ressourcen können auch zwischen den DevOps-Teams rotieren, um einen organisationsübergreifenden Wissensstand aufzubauen und Silo-Wissen zu vermeiden. Die Entscheidung, welche Topologie auf Ihre Organisation anzuwenden ist, sollte immer unter der Berücksichtigung der Firmenkultur und den bestehenden Kompetenzen der Mitarbeiter erfolgen. Das Modell sollte jedoch dem Prinzip der Geschwindigkeitserhöhung im Integrations- und Betriebslebenszyklus folgen.

Absicherung mit einer Kubernetes-Security

Sobald Sie die kulturellen Voraussetzungen ihrer Organisation auf dem richtigen Weg sehen, sollten Sie sich der Absicherung ihrer Kubernetes-Cluster widmen. Die Autoren unterscheiden hier drei Ziele, die Angreifer auf Kubernetes-Cluster verfolgen können:

  1. Verlust/Raub von Daten und/oder Dateien innerhalb und außerhalb des Clusters (z. B. Container- und/oder Clusterausbrüche)
  2. Finanzielle Schäden durch den Missbrauch von Systemressourcen (z. B. Mining-Malware)
  3. Teilweiser oder vollständiger Systemausfall aus schadhafter Intension (z. B. Hacktivism)

Kubernetes-Security im Architekturdesign

Um diesen Gefahren entgegenzuwirken, sollten Sie einen Blick auf die einzelnen Komponenten des Clusters werfen.

  • (Virtuelle) Infrastruktur: Für die Installation einer Kubernetes-Umgebung ist zunächst die Bereitstellung der Basisinfrastruktur notwendig. Der Kubernetes-Cluster kann hierbei auf sowohl eigenen (Bare-Metal-)Servern oder Public-Cloud-Instanzen aufgesetzt sein. Die Absicherung der Infrastruktur ist üblicherweise bereits im eigenen Sicherheitskonzept der Clusterbetreiber definiert und schützt die Organisation nach den hauseigenen oder allgemein gängigen Standards. Da ein gängiges Sicherheitskonzept für die Bereitstellung von Infrastruktur in jeder Organisation existieren sollte (gemäß BSI-Grundschutz), fokussiert sich der Artikel auf die Kubernetes-eigenen Komponenten:
  • Kubernetes: Die Architektur von Kubernetes teilt sich in mehrere Teilkomponenten auf, die für die Orchestrierung und den Betrieb von Microservices notwendig sind. Die erste Ebene stellt wie in fast allen verteilten IT-Plattformen ein Netzwerk aus einem Master und mehren Worker Nodes dar.
  • Master Node: Der Master Node stellt die API-Schnittstelle zum Cluster bereit und beinhaltet gleichzeitig die relevanten Teilkomponenten, die zur Verwaltung und Nutzung notwendig sind, wie den API-Server, den Service-Controller-Manager zur Verarbeitung der Replikationsprozesse und den Scheduler zur Lastverteilung zwischen den Worker Nodes.
  • Worker Nodes: Die Worker Nodes betreiben die Applikationscontainer des Netzwerks. Jeder Worker Node beinhaltet hierzu primär eine Container-Runtime und einen Agenten, der mit dem Master Node kommuniziert.
  • Pods und Services: Ein Pod ist die kleinste deploybare Einheit in einem Kubernetes-Netzwerk und besteht aus einem oder mehreren instanziierten Containern sowie den für deren Betrieb notwendigen Ressourcen. Jeder Pod hat hierbei seine eigene netzwerkinterne IP-Adresse und wird mit Hilfe von Services angesteuert. Ein Service funktioniert als Proxy für die Pods und verteilt die Lasten über replizierte Pods hinweg. Services ermöglichen auch den externen Zugriff auf Pods mit Hilfe von externen IPs und NodePorts.
  • Container-Images: Ein Container-Image ist ein Speicherabbild eines Containers und enthält eine Applikation und alle Ressourcen und Bibliotheken, die zur Ausführung der Applikation benötigt werden. Im erstellten Zustand ist ein Container-Image unveränderbar. Wenn von Containern gesprochen wird, versteht man darunter im allgemeinen Docker-Container, die sich bisher als Virtualisierungsstandard etabliert haben. Es sei hierbei aber auch darauf hingewiesen, dass es bereits weitere Kubernetes-kompatible Alternativen gibt, wie zum Beispiel rtk aus dem Hause CoreOS, die ihren eigenen Formatstandard mitbringen.
  • Applikation: Die Applikation ist die containerisierte Anwendung, die je nach Art und Beschaffenheit des Microservice eine Weboberfläche und oder Funktion bereitstellt und auf Dateien und Daten zugreifen kann.

Kubernetes-Security startet bereits mit dem Design und der Vorkonfiguration dieser Komponenten. Eine gute Orientierungshilfe zur Vorkonfigurationen bieten stets die Vorgaben aus der Kubernetes-Dokumentation. Die Absicherung des Clusters ist ein vielschichtiger Prozess und eine Vielzahl von Konfigurationen auf unterschiedlichen Ebenen ist möglich. Die Grafik in Abbildung 2 fasst die aus Sicht der Autoren wichtigsten Konfigurationsaspekte für ein Cluster-Set-up zusammen.

Abb. 2: Grundlegende Sicherheitsmechanismen im Kubernetes-Design

Abb. 2: Grundlegende Sicherheitsmechanismen im Kubernetes-Design

Mit der Absicherung der Systemressourcen auf dem Masterknoten anfangen

Welche Sicherheitsmaßnahmen können konkret getroffen werden? Integrieren Sie einen Authentifizierungsmechanismus (am besten einen bereits im Unternehmen verwendeten Dienst) für das Kubernetes API, um die Zugänge Ihrer Nutzer, Nodes und Kommunikationskomponenten (Proxies-Scheduler, Volume-Plug-ins) zu steuern und revisionssicher zu prüfen. Ebenso sollten Sie die integrierte Role-based-Access-Control-(RBAC-)Komponente nutzen, um die Zugänge Ihrer Nutzer einzuschränken. Deaktivieren Sie unter keinen Umständen die Transport Level Security (TLS) für den API-Traffic, da sonst der Datenverkehr zwischen Ihren Pods unverschlüsselt erfolgt.

Als Nächstes sollten Sie auch die erreichbaren Funktionalitäten des Kubelet-Dienstes einschränken. Kubelet erlaubt den Zugang über HTTPS-Endpunkte und stellt sicher, dass alle Container in ihrem gewünschten Zustand laufen. Standardmäßig erlaubt Kubelet alle authentifizierten und autorisierten Requests, wodurch beliebige Befehle an Pods gesendet werden können. Besonders gefährlich ist, dass selbst die Einschränkung des Zugriffs über signierte Zertifikate das HTTP API zugänglich machen. Wenn möglich, sollte daher der –read-only-port für Kubelet deaktiviert werden, um den Zugang nur noch über valide HTTPS-Zertifikate zu erlauben. Zu guter Letzt können Sie die Sicherheit der API-Dienste um eine automatisierte Key-Rotation ergänzen, um die Gefahren durch kompromittierte Schlüssel und Zertifikate zu limitieren. Denken Sie auch daran, Ihren Auditlog zur besseren Nachvollziehbarkeit der zum API-Server gesendeten Anfragen zu aktivieren.

Absicherung der Worker Nodes und Infrastruktur

Nach der Einschränkung der API-Zugriffe können Sie sich der Absicherung der Worker Nodes widmen. Da Worker Nodes lediglich Container ausführen, sollte zunächst nur ein minimalisiertes Betriebssystem laufen. Wenn möglich, sollten Sie die Linux Capabilities einschränken, SELinux aktivieren und Seccomp nutzen. Gleichzeitig sollten Ihre gängigen Methoden zur Absicherung der physischen und virtuellen Infrastruktur wie z. B. Sicherheitsgruppen, Firewalls und Endpoint-Security-Agenten aktiviert sein.

Absicherung der Pods, Container-Images und Applikationen

Widmen wir uns nun der Absicherung Ihrer Pods. Definieren Sie zunächst über die .yaml-Dateien geeignete Ressourcen- und Speicherlimits Ihrer Pods. Das verhindert, dass kompromittierte Pods übermäßig auf die Ressourcen des darunter liegenden Worker Nodes zugreifen können. Setzen Sie auch einen Wert für MaximumRetryCount, um die Installation beschädigter Pods nach einer definierten Anzahl an Versuchen abzubrechen und PIDs-Limits, um den ungewollten Verbrauch von Systemressourcen zu limitieren. Die Aktivierung von Health Checks dient Ihnen zur besseren Nachverfolgung Ihrer Pod Deployments.

Als Nächstes können die in den Pods verwendeten Container-Images konfiguriert werden. Eine erste Sicherheitsmaßnahme ist, Container grundsätzlich nicht als root-User auszuführen. So können größere Schäden vermieden werden, selbst wenn sich ein Angreifer Zugriff verschafft. Sie sollten auch Ihre Base Images stets up to date halten, um gegen die neuesten Vulnerabilities geschützt zu sein. Analog zu den Base Images müssen auch die für die containerisierten Anwendungen notwendigen Libraries und Packages aktualisiert sein.

Service Mesh

Wenn mehrere miteinander verbundene Microservices eine Anwendung bilden, ist dieses Geflecht ein Service Mesh. Die Service Meshes werden immer komplexer, umso länger eine Anwendung existiert. Laut Michael Hofmann und Markus Lackner trägt jede neue Versionen des notwendigen Microservice, die Skalierung zur Ausfallsicherheit und Lastverteilung, Staging-Umgebungen oder Multi-Mandanten-Anforderungen zur Service-Anzahl bei. Um Ihre Service Meshes besser beherrschen zu können, sollten Sie die Nutzung von Service-Mesh-Werkzeugen wie Istio, oder Linkerd 2 – die mit leichtgewichtigen Reverse Proxies (Sidecar-Prozessen) den Netzwerkverkehr vom eigentlichen Microservice-Verkehr rauslöst – in Erwägung ziehen. Istio und Linkerd 2 bieten Funktionalitäten zur Authentifizierung, Autorisierung und Kommunikationsverschlüsselung zwischen den Microservices und tragen somit positiv zur Sicherheit bei. Die Entscheidung zur Nutzung eines Service-Mesh-Werkzeugs sollte noch vor dem Aufsetzen des Clusters getroffen werden, da die nachträgliche (De-)Installation zu Problemen in der Service-to-Service-Kommunikation führen kann.

Kubernetes-Security im CI/CD-Prozess

Eine besondere Chance bietet die Integration von Securitymethoden in der CI/CD Pipeline. Anstelle des traditionellen Ablaufs von Securitytests, die zum Nachpatchen monolithischer Anwendungen genutzt werden, kann durch die Integration von Compliance as Code, Security-Scanning-Tools und automatisierter Securitytests auch in der IT-Security ein Shift Left erreicht werden.

Starten Sie mit einem Security-by-Design-Ansatz, indem Sie mit Hilfe von PodSecurityPolicies eine Mindestsecuritykonfiguration definieren. Die folgende PodSecurityPolicy verhindert clusterübergreifend zum Beispiel die Ausführung privilegierter Container und verbietet die Verwendung von root-Usern.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: securityBaseline
spec:
privileged: false
runAsUser:
rule: MustRunAsNonRoot

Sie können PodSecurityPolicies aber auch als Prüfwerkzeug in Ihrer CI/CD Pipeline verwenden. Mit Hilfe von https://kubesec.io/ können Sie ein Scoring für die Verletzung gegen Mindestkonfigurationen definieren und bei einer Verletzung des Schwellenwerts während des Deployments aussteuern. Diesen Ansatz können Sie gleichzeitig auch für das Ausrollen neuer Worker Nodes nutzen, indem Sie beispielsweise mit Hilfe von Chef InSpec Ihre Standardkonfigurationen definieren. Compliance as Code bietet der IT-Security einen weiteren signifikanten Vorteil, da auch gegen regulatorische Standards wie die Datenschutzgrundverordnung oder PCI DSS geprüft werden kann und die Ergebnisse für das Reporting verwendet werden können.

Codes und Container-Images prüfen

Neben der Definition Ihrer eigenen Security-Baseline sollten Sie sowohl den Code Ihrer containerisierten Anwendungen als auch die Container-Images während des Builds auf Schwachstellen und Schadsoftware überprüfen. Hierfür gibt es eine Vielzahl von Open-Source- und lizenzbasierten Lösungen auf dem Markt. Bei den lizenzbasierten Lösungen sollte eine Prüfung der bereits im Unternehmen verbauten Securitytechnologien und Anbieter durchgeführt werden, um Synergien zu schaffen. Besonders die Schwachstellenanalyse auf Softwarecode ist in den letzten Jahren weit gekommen und verschiedene Anbieter ermöglichen Ihnen sogar die Überprüfung der Lizenzbeschaffenheit von verwendeten externen Packages. So können Sie sich auch gegen Lizenzklagen schützen. Zu guter Letzt können Sie auch Securitytests wie Penetrationstests automatisieren. Das Open Source Framework Gauntlt bietet Ihnen zum Beispiel die Möglichkeit, Angriffe in Gherkin-Syntax mit verschieden Werkzeugen wie cURL, Arachni, DIRB, Heartbleed, Nmap, SSLyze, sqlmap oder Garmr zu skripten und auszuführen. Es steht Ihnen frei, welche Lösungen und Prüfungen Sie in Ihre CI/CD Pipeline einbauen möchten. Denken Sie aber an eine geeignete Aussteuerungslogik und schaffen Sie geschlossene Feedbackloops (z. B. automatisierte Ticketerstellung), um die Sicherheitsverstöße und Testergebnisse nachzubessern.

Sprechen wir nun über den passenden Zeitpunkt, zu dem Sie Ihre Tests in der CI/CD Pipeline integrieren sollten. Anwendungsspezifische Tests wie Dependency Checks oder Open Source Verification sollten Sie idealerweise vor dem Bau Ihrer Container-Images durchführen. Hier eignen sich zum Beispiel Tests, die nach dem Commit auf Ihr Code/GitRepository gestartet werden und den Entwickler direkt auf Schwachstellen hinweisen. Die Überprüfung Ihrer Container-Images folgt während des Image Builds. Machen Sie sich hierbei die Vorteile einer privaten Image Registry zunutze, die Sie als sichere Anlaufstelle definieren können. Erlauben Sie nur Container-Images in der privaten Registry, die Ihre Tests bestehen. Zusätzlich sollten Sie vermeiden, dass beliebige Nutzer neue Container-Images außerhalb der private Registry deployen können. Hierfür können Sie die RBACl im Zusammenspiel mit PodSecurityPolicies verwenden.

Sollten Sie das Trust-Level in Ihrem CI/CD-Prozess zusätzlich erhöhen wollen, können Sie auch auf das Konzept von Code- und Containersignierung zurückgreifen. Für Container-Images können Sie zum Beispiel einen (privaten) Docker-Notary-Server und Signer in Kombination mit Portieris nutzen. Portieris ist ein Admission Controller, der von IBM als Open-Source-Lösung bereitgestellt wird und sicherstellt, dass nur Images deployt werden dürfen, die vorher signiert wurden.

Die Integration von Securitymechanismen in den CI/CD-Prozess ist oft die größte Herausforderung für die Anwender. Hierfür gibt es mehrere Gründe: Oftmals fehlt es an der Schnittstellenkompetenz zwischen der Definition von Konfigurationsskripten und tiefgehendem IT-Security-Verständnis. DevOps-Teams haben das Know-how, Policies zu definieren, jedoch fehlen ihnen die Kenntnisse über die internen und externen Complianceanforderungen. Die IT-Security-Experten sind hingegen oftmals nicht in der Lage, die notwendigen Anforderungen zu codifizieren. Zusätzlich müssen die Policies vom Team verwaltet und die Verantwortlichkeiten zur Nachbesserung in gescheiterten Testfällen geklärt sein. Dies verdeutlicht nochmal, warum die Schaffung der kulturellen Voraussetzungen ein elementarer Bestandteil der Kubernetes-Security ist.

IT-Security in produktiven Kubernetes-Umgebungen

Der Kubernetes-Cluster in Produktion ist wohl der wichtigste Aspekt, wenn es um das Thema Security geht. Achten Sie zunächst darauf, dass Ihre Worker Nodes gemäß ihrer IT-Sicherheitsstandards mit Securityagenten und Endpoint Detection ausgestattet sind.

Die große Herausforderung, die Kubernetes und alle darauf basierenden Lösungen am heutigen Markt haben, ist wohl die fehlende Transparenz über die aktive Kommunikation zwischen den Pods. Klassische IT-Security-Systeme installieren sich normalerweise auf der virtuellen Instanz der Nodes und sind blind, wenn es um die Kommunikation auf Layer 7 geht. Diese Securitylösungen können unter gegebenen Umständen zwar prüfe,n ob Pakete einen Kubernetes,Cluster verlassen, jedoch sind die Inhalte verschlüsselt und eine Feststellung, ob sensible Daten aus dem Netz extrahiert wurden, ist nicht möglich. Durch die Aktivierung von Service-Mesh-Werkzeugen wie Istio oder Linkerd 2 erhöhen Sie die Komplexität der Layer-7-Kommunikation noch weiter, was ein manuelles Monitoring nahezu unmöglich macht.

Eine weitere Gefahr besteht, weil produktive Cluster trotz automatisierter Tests in der CI/CD Pipeline nicht gegen Zero-Day-Attacken und Insiderangriffe geschützt sind. Je nach Nutzung der Sicherheitsmechanismen vor Produktivgang besteht daher die Gefahr, dass

  • schadhafte Pods in dem Cluster gestartet werden,
  • Container schadhafte Prozesse ausführen oder
  • aus Containern ausgebrochen und auf andere Ressourcen zugegriffen wird.

Da Orchestrierungs- und Containermanagementtools wie zum Beispiel die Kubernetes-Administrationskonsole nicht als Securitytools ausgelegt sind, sollten Sie von einer Containerfirewalllösung wie NeuVector, vArmour oder Sysdig Secure zum Schutz während der Runtime Gebrauch machen. Containerfirewalls verschaffen Ihnen hierbei einen entscheidenden Vorteil, da nahezu alle Lösungen die laufende Layer-7-Kommunikation visualisieren können. Eine Darstellung, wie komplex diese Kommunikation aussieht, können Sie dem Screenshot aus der NeuVector-Konsole in Abbildung 3 entnehmen.

Abb. 3: Kommunikationspfade in einem produktiven Kubernetes-Netzwerk

Abb. 3: Kommunikationspfade in einem produktiven Kubernetes-Netzwerk

Wir bei NTT DATA haben uns in diesem Bereich für die Lösung von NeuVector entschieden, die sich direkt als Container-Pods auf dem Kubernetes-Cluster deployen lässt. NeuVector lernt sofort nach dem Deployment die standardmäßige Kommunikation zwischen den Containern und kann darauf automatisiert die Netzwerk-Policies in einer Whitelist generieren, was die Policy-Administration deutlich erleichtert. Zudem beinhaltet die Lösung eine Deep Packet Inspection (DPI) und Data Loss Prevention (DLP), die den Traffic zwischen den Pods inhaltlich analysiert und so die Art des Angriffs, z. B. schadhafte HTTP Requests oder Daten-Exfiltration offenlegt. Die Administration und Nutzung von Containerfirewalls sollte in der Hand des clusterbetreibenden DevOps-Teams liegen, um möglichst schnell auf Angriffe reagieren zu können. Eine Schnittstelle zu Reportingtools und SIEM-Lösungen ermöglicht auch Silo-basierten Organisationen eine Integration ins Securitymonitoring.

Zusammenfassung und Ausblick – drei Handlungsempfehlungen

Die Absicherung von Kubernetes-Umgebungen ist ein eng verflochtenes Zusammenspiel aus einer interaktiven Zusammenarbeit zwischen Securityexperten und DevOps-Teams bezüglich der richtigen Vorkonfigurationen und Securitychecks während des Deployments von Knoten und Microservices und der aktiven Überwachung produktiver Cluster. Die folgenden drei Handlungsempfehlungen sollten noch einmal die wichtigsten Maßnahmen zusammenfassen:

  • Schaffen Sie die kulturellen Voraussetzungen in Ihrer Organisation und binden Sie Ihre IT-Security-Einheiten frühzeitig ein. Communityansätze oder das Shadowing können Ihnen bei der Sensibilisierung helfen.
  • Machen Sie sich Security-Policies, Schwachstellenanalysen und automatisierte Tests in Ihren Deployment-Prozessen zunutze. Achten Sie neben einer geeigneten Vorkonfiguration des Kubernetes-Clusters auch auf den Schutz Ihrer Entwicklungstools mit Hilfe eines adäquaten Zugangsmanagements und vermeiden Sie um jeden Preis die Nutzung von Standardpasswörtern auf allen Ebenen.
  • Sorgen Sie für Transparenz in Ihren Produktivumgebungen, um Ausbrüche aus Containern und Schwachstellen zu vermeiden und das Deployment fremder Pods rechtzeitig zu erkennen. Greifen Sie hierzu auch auf Containerfirewalls für eine Transparenz auf der Layer-7-Kommunikation zu und vergessen Sie nicht Ihre Standardsecuritytools zur Absicherung der unterliegenden (virtuellen) Infrastruktur.

Fazit

Die Zukunft von Microservices liegt in Kubernetes. Die Kubernetes-Community wächst dank des Open-Source-Ansatzes kontinuierlich. Neue Tools, Add-ons und Plug-ins kommen nahezu täglich hinzu. Es sollte jedoch nicht vergessen werden, dass Kubernetes ursprünglich lediglich als Open Source Framework gedacht war und die Absicherung der Technologie dadurch so facettenreich wie deren Anwendungsfälle sind. Die Autoren sehen hierbei auch einen zunehmenden Trend, Kubernetes-Cluster nicht mehr als „Pets“ (Haustiere) zu betrachten, die hütend gepflegt werden, sondern als austauschbares „Cattle“ (Vieh). Dieser Trend wird verlangen, dass das Zerstören und Konstruieren von sicheren Kubernetes-Clustern künftig zum Alltag gehören wird. Dies kann jedoch nur funktionieren, wenn sich die Anwender über ihr Bild eines sicheren Clusters bewusst sind. Die IT-Security für Kubernetes bleibt also auch zukünftig spannend.

Geschrieben von
Maximilian Siegert
Maximilian Siegert
Maximilian Siegert ist Business Development Manager bei der IT-Security Solution Sales der NTT DATA Deutschland GmbH. Er verantwortet zusammen mit Patrice Volkmer das Business Development im Bereich IT-Security der NTT DATA Deutschland GmbH. Sein Fokus liegt insbesondere auf den Themen DevSecOps, Cloud und Containersecurity. Im Zuge seiner Rolle verantwortet er auch die fachliche und technische Integration bestehender Standardsecuritylösungen von führenden IT-Security-Partnern in den firmeneigenen OpenShift- und Kubernetes-Templates.
Patrice Volkmer
Patrice Volkmer
Patrice Volkmer ist Alliance Manager & Client Partner bei der IT-Security Solution Sales der NTT DATA Deutschland GmbH. Zuvor war er bei der NTT Security tätig. In seiner Rolle kümmert er sich in erster Linie um das Business Development und unterstützende Begleitung in vielen IT-Security-Projekten. Insbesondere die Kundenbetreuung von komplexen großen IT-Security-Projekten liegt ihm am Herzen. Er trägt die Verantwortung für die strategische Kundenberatung und ist für die Kooperation mit Produktpartnern im IT-Security-Umfeld verantwortlich.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: