Warum ist die Absicherung von Kubernetes so schwierig?

Die Sicherheit muss ein integraler Bestandteil des Lebenszyklus in der Software-Entwicklung sein, der bei jedem Schritt des Prozesses berücksichtigt wird. Dies ist der erste Teil der Artikelreihe „Absicherung von Kubernetes für native Cloud-Anwendungen“. Puja Abbassi, Developer Advocate & Product Owner bei Giant Swarm, beleuchtet darin im Detail die Sicherheitsaspekte einer Kubernetes-Plattform.

Falls Sie mit Kubernetes vertraut sind, wird die im Titel stehende Frage vermutlich tief in Ihrem Wesen nachklingen. Falls Sie mit Ihrer cloud-nativen Reise gerade erst beginnen und Kubernetes Ihnen als drohender Berg erscheint, den Sie bezwingen müssen, so werden Sie schnell erkennen, welche Relevanz die Frage hat.

Sicherheit ist im besten Fall nur schwierig. Wenn Ihre Software-Anwendungen aber aus einer Vielzahl von kleinen, dynamischen, skalierbaren, verteilten Microservices bestehen, die in Containern laufen, dann wird es noch schwieriger. Es ist nicht nur die Vergänglichkeit der Umgebung, welche diese Schwierigkeiten verstärkt, sondern auch die Einführung neuer Workflows und Toolchains, die alle jeweils eigene, neue Sicherheitsaspekte einbringen.
Lassen Sie uns dieses Thema etwas vertiefen.

Fähigkeiten

Zunächst einmal sind Kubernetes und einige der anderen Tools, die in der Liefer-Pipeline containerisierter Mikroservices eingesetzt werden, komplex. Sie haben eine steile Lernkurve, unterliegen einem aggressiven Release-Zyklus mit häufigen Änderungen und erfordern erhebliche Anstrengungen, um alle nuancierten Fragen der Plattformsicherheit nicht aus dem Auge zu verlieren. Falls die für die Sicherheit verantwortlichen Teammitglieder nicht verstehen, wie die Plattform gesichert werden sollte – oder schlimmer noch: es wurde niemand mit dieser Verantwortung betraut – so könnte es auf der Plattform eklatante Sicherheitslücken geben. Dies könnte sich im besten Falle als peinlich erweisen und schlimmstenfalls schädliche Folgen haben.

Schwerpunkt

In dem Bestreben, ein innovativer Vorreiter auf ihrem gewählten Markt zu werden, oder als Reaktion auf externe Markteinflüsse (z. B. Kundenanforderungen oder die Aktivitäten von Wettbewerbern) agiler zu sein, sind neue und alte, kleine und große Unternehmen damit beschäftigt, DevOps-Praktiken anzuwenden. Der Schwerpunkt liegt auf der Geschwindigkeit der Bereitstellung neuer Funktionen und Lösungen. Dabei verschwimmen die traditionellen Grenzen zwischen Entwicklung und Betrieb. Es ist großartig, dass wir bei Entwicklung und Definition unserer Integrations-, Test- und Lieferpipeline die operativen Aspekte berücksichtigen. Wie aber sieht es mit der Sicherheit aus? Sicherheit sollte kein nachträglicher Gedanke sein: Sie muss ein integraler Bestandteil des Lebenszyklus in der Software-Entwicklung sein, der bei jedem Schritt des Prozesses berücksichtigt wird. Leider ist dies oft nicht der Fall. Dabei wird aber die Notwendigkeit deutlicher, dass die Sicherheit mit in den Vordergrund gerückt und Teil der Liefer-Pipeline werden muss. Die Praxis ist geprägt von DevSecOps oder kontinuierlicher Sicherheit.

Komplexität

Wir haben bereits darauf hingewiesen, dass Kubernetes und seine symbiotischen Werkzeuge komplex und etwas schwierig zu beherrschen sind. Aber es wird leider noch schlimmer, denn es gibt mehrere Ebenen im Kubernetes-Stapel, die jeweils ihre eigenen Sicherheitsüberlegungen haben. Es reicht schlicht nicht aus, eine Ebene zu sperren, während die anderen Ebenen, aus denen der Stapel besteht, vergessen werden. Das wäre in etwa wie das Verriegeln der Tür, während die Fenster weit geöffnet bleiben.

Die Berücksichtigung und Einführung mehrerer Sicherheitsebenen zieht mehr Komplexität nach sich. Aber es hat auch einen positiven Nebeneffekt: Es bietet eine „tiefgehende Verteidigung“. Wenn ein potenzieller Angreifer einen Sicherheitsmechanismus umgeht, so kann ein anderer Mechanismus der gleichen oder einer anderen Ebene eingreifen und den Angriff wirkungslos machen.

Absicherung aller Ebenen

Welche Ebenen einer Kubernetes-Plattform müssen also gesichert werden?

Zunächst gibt es eine Infrastrukturebene, die aus Maschinen und den dazwischen liegenden Netzwerkverbindungen besteht. Die Maschinen können aus physischen oder abstrahierten Hardware-Komponenten bestehen und ein Betriebssystem sowie (meist) die Docker Engine ausführen. Zudem gibt es eine weitere Infrastrukturebene, die aus den Kubernetes-Cluster-Komponenten, den auf den Master Node laufenden Komponenten der Steuerebene und den mit Container-Workloads interagierenden, auf Worker Nodes laufenden Komponenten besteht. Die nächste Ebene befasst sich mit der Anwendung verschiedener Sicherheitskontrollen auf Kubernetes, um den Zugriff auf und innerhalb des Clusters zu steuern, Richtlinien für die Ausführung der Container-Workloads festzulegen und eine Isolierung der Workloads zu gewährleisten. Schließlich befasst sich eine Workload-Sicherheitsebene mit Sicherheit, Herkunft und Integrität der Container-Workloads selbst. Diese Sicherheitsebene sollte sich nicht nur mit den Tools befassen, welche das Sicherheitsmanagement der Workloads unterstützen, sondern auch mit der Frage, wie diese Tools in den End-to-End-Workflow integriert werden.

Einige allgemeine Themen

Es ist gut zu wissen, dass es einige gemeinsame Sicherheitsthemen gibt. Diese durchlaufen die meisten Ebenen, welche unsere Aufmerksamkeit erfordern. Eine frühzeitige Anerkennung und ein konsistenter Ansatz bei der Anwendung können zur Umsetzung der Sicherheitsrichtlinie einen erheblichen Beitrag leisten.

• Prinzip des geringsten Privilegs. Ein in der IT-Sicherheit allgemein verbreitetes Prinzip, bei dem der Zugriff von Benutzern und Anwendungsdiensten auf verfügbare Ressourcen so beschränkt ist, dass er nur ausreicht, um die zugewiesene Funktion auszuführen. Das trägt dazu bei, eine Eskalation der Privilegien zu verhindern. Wenn beispielsweise eine Container-Workload kompromittiert wird und mit gerade genug Privilegien bereitgestellt wurde, damit er seine Aufgabe erfüllen kann, ist der Ausfall des Kompromisses auf die dem Workload zugeordneten Privilegien beschränkt.
• Softwarewährung. Eine Aktualisierung der Software ist für die Sicherheit von Plattformen entscheidend. Es ist völlig klar, dass sicherheitsrelevante Patches so schnell wie möglich eingespielt werden sollten. Andere Softwarekomponenten sollten in einer Testumgebung gründlich ausprobiert werden, bevor sie auf Produktionsdienste angewendet werden. Bei der Bereitstellung brandneuer Hauptversionen (z. B. 2.0) ist einige Vorsicht geboten. Als Faustregel wird davon abgeraten, Alpha-, Beta- oder Release Candidate-Versionen in Produktionsumgebungen einzusetzen. Interessanterweise gilt dies nicht unbedingt für mit Kubernetes-Objekten verknüpfte API-Versionen. Die API für das häufig verwendete Ingress-Objekt war beispielsweise seit Kubernetes v1.1 in der Version v1beta1.
• Protokollierung & Überprüfung. Die Fähigkeit, zurückzuschauen, um zu sehen, was oder wer eine bestimmte Aktion oder Aktionskette eingeleitet hat, ist für eine Aufrechterhaltung der Sicherheit einer Plattform äußerst wertvoll. Die Protokollierung der Prüfereignisse sollte auf allen Ebenen des Plattformstapels konfiguriert sein. Das schließt die Überprüfung der Kubernetes-Cluster-Aktivität mithilfe von Prüfrichtlinien ein. Prüfprotokolle sollten gesammelt und mit einem Log-Shipper wie beispielsweise Fluentd oder Filebeat an ein zentrales Repository gesendet werden, wo sie für eine spätere Analyse mit einem Tool wie Elasticsearch oder einem Public-Cloud-Äquivalent gespeichert werden können.
• Kompromiss zwischen Sicherheit und Produktivität. Unter bestimmten Umständen kann Sicherheit als Hemmnis für die Produktivität gesehen werden. Das gilt vor allem für die Produktivität der Entwickler. Das mit der Ausführung von privilegierten Containern verbundene Risiko – z. B. in einem Cluster für Entwicklung – könnte verschmerzbar sein, wenn das Entwicklungsteam dadurch schneller arbeiten kann. Der Kompromiss zwischen Sicherheit und Produktivität (und anderen Faktoren) wird für eine Entwicklungsumgebung, eine Produktionsumgebung und sogar eine „Sandkasten“-Umgebung zum Lernen und Ausprobieren ganz unterschiedlich sein. Was in der einen Umgebung inakzeptabel ist, kann in einer anderen durchaus akzeptabel sein. Dabei sollte jedoch das mit gelockerten Sicherheitsbeschränkungen verbundene Risiko nicht einfach außer Acht gelassen werden. Es sollte sorgfältig berechnet und nach Möglichkeit eingedämmt werden. So kann der Einsatz privilegierter Container beispielsweise durch Kubernetes‘ eigene Sicherheitskontrollen wie beispielsweise RBAC und Pod Security Policies reduziert werden.

Serienübersicht

Es ist schwierig, aber nicht unmöglich, die Sicherheit auf einer Kubernetes-Plattform zu konfigurieren! Dies ist die Einleitung einer Artikelreihe mit dem Titel Absicherung von Kubernetes für native Cloud-Anwendungen, die darauf abzielt, die Sicherheitsaspekte einer Kubernetes-Plattform aufzuzeigen. Wir können nicht jedes Thema und jede Facette abdecken. Dennoch werden wir versuchen, einen guten Überblick über die Sicherheitsanforderungen in jeder Ebene zu vermitteln sowie einige unserer Erfahrungen mit dem Betrieb von Kubernetes-Clustern in Produktion für unsere Kunden zu präsentieren.