Wie KernelCare Ihnen dabei hilft, Ihre containerisierten Workloads sicher zu halten

Die Betriebssystemvirtualisierung war ein großer Schritt nach vorn für die Bereitstellung groß angelegter Computeranwendungen in Unternehmen. Aber virtuelle Maschinen waren nur der Anfang. Mit Containern geht die Virtualisierung noch einen Schritt weiter und bietet eine noch nie dagewesene Flexibilität, da die Anwendungen fast nahtlos transportiert werden können.

Container bergen jedoch ein verstecktes Sicherheitsrisiko, das sich aus der Natur der Containerisierung ergibt. In diesem Artikel erörtern wir die Rolle der Containerisierung im Unternehmen, erklären, warum Container ein Sicherheitsrisiko für Unternehmen darstellen können, und zeigen effektive Lösungen auf.

Inhalte:

1. Was ist eine containerisierte Arbeitslast?

2. Von der Virtualisierung zur Containerisierung

3. Wie Container im Unternehmen eingesetzt werden

4. Die Beziehung zwischen Containern und dem Host

5. Isoliert, ja, aber immer noch verletzlich

6. Ungepatchte Kernel: Ein verstecktes Container-Sicherheitsrisiko?

7. Das Problem beim Patchen von Kerneln

8. KernelCare Live-Patching-Integration

9. Weitere Tipps für die Sicherheit des Container-Kernels

10. Schlussfolgerung

Bleiben Sie dran. Was ist eine containerisierte Arbeitslast?

Um zu verstehen, warum Container ein Sicherheitsrisiko darstellen können, muss man wissen, was genau ein Container ist - und was eine containerisierte Arbeitslast ist.

Gehen wir zunächst einen Schritt zurück zur Virtualisierung. Vor nicht allzu langer Zeit waren das Betriebssystem eines Computers und die Hardware, auf der es läuft, untrennbar miteinander verbunden - ein physischer Server ist mit einem Betriebssystem verbunden. Die Virtualisierung ändert dies, indem sie eine Schicht zwischen der Hardware und dem darauf laufenden Betriebssystem einfügt. Sie hebt die eins-zu-eins-Beziehung zwischen Betriebssystem und Hardware auf.

Für ein virtualisiertes Betriebssystem sieht es so aus, als ob es das einzige Betriebssystem auf der Hardware wäre. Im Hintergrund verwaltet die Virtualisierungssoftware (der Hypervisor) die Abstraktionsschicht, um sicherzustellen, dass jedes Betriebssystem nichts von der Anwesenheit anderer Betriebssysteme auf dem Rechner weiß.

Dank der Virtualisierung können Sie mehrere Betriebssysteme auf einem Rechner ausführen und ein Betriebssystem problemlos von einem Rechner auf einen anderen übertragen. Das Ergebnis ist eine Steigerung der Effizienz und Flexibilität.

Von der Virtualisierung zur Containerisierung

Wir verweisen auf die Virtualisierung, weil sie hilft zu erklären, was die Containerisierung bewirkt. Während die Virtualisierung eine Abstraktionsebene zwischen die physische Ausrüstung und das Betriebssystem setzt, fügt die Containerisierung eine Abstraktionsebene zwischen das Betriebssystem und die Anwendung.

Während die Virtualisierung im Wesentlichen die Hardware virtualisiert, wird bei der Containerisierung das Betriebssystem virtualisiert . Bei der Containerisierung wird jede Anwendung in eine isolierte Einheit, einen Container, gekapselt. Containerisierte Anwendungen nutzen die Betriebssystemumgebung nicht gemeinsam, da jeder Container für sich arbeitet.

Allerdings haben Container gemeinsamen Lesezugriff auf Elemente des Betriebssystems, einschließlich seines Kerns. Dennoch sieht es für jede Anwendung so aus, als würde sie allein in einem eigenen Betriebssystem laufen - und die Anwendungen wissen nicht, dass sie die Betriebssystemumgebung gemeinsam nutzen.

Folglich bezieht sich eine containerisierte Arbeitslast auf eine Umgebung, in der die Anwendungen, die die Unternehmensanforderungen unterstützen, in isolierten Containern innerhalb eines Host-Betriebssystems ausgeführt werden.

Wie Container im Unternehmen eingesetzt werden

Man könnte meinen, dass die Isolierung von Anwendungen innerhalb von Containern Vorteile in Bezug auf Sicherheit und Stabilität bietet, und damit hätte man Recht. Die Vorteile der Containerisierung gehen jedoch weit darüber hinaus.

Im Kern ermöglicht die Containerisierung Unternehmen, Anwendungen auf standardisierte Weise zu verpacken und über verschiedene Arten von Infrastrukturen hinweg bereitzustellen. Theoretisch ist jeder Host, der in der Lage ist, einen (kompatiblen) Container zu hosten, auch in der Lage, Ihre containerisierte Anwendung zu hosten.

Dies geschieht, weil die Containerisierung die Anwendungsschicht abstrahiert. Containertechnologie wie Docker erleichtert diese Abstraktion in einer standardisierten Weise. Der Schlüssel zu diesem standardisierten Verhalten ist ein so genanntes Container-Image. Ein Container-Image enthält nicht nur den Anwendungscode, sondern auch Systembibliotheken und andere wichtige Einstellungen, die sicherstellen, dass eine containerisierte Anwendung einsatzbereit ist.

Dies bringt uns zu einem entscheidenden Vorteil der Containerisierung, der über die Sicherheit und Stabilität von Anwendungen hinausgeht: Container sind von Natur aus portabel. Daraus ergeben sich mehrere wichtige Vorteile für Unternehmensanwendungen:

• Portabilität bedeutet Agilität. Containerisierte Anwendungen können problemlos in einer neuen, unbekannten Umgebung ausgeführt werden. Ein Entwickler kann ein Container-Image veröffentlichen, und Unternehmenskunden können die Anwendung ohne Bedenken einsetzen, solange der Container in eine standardisierte Containerumgebung wie Docker passt. Container ermöglichen eine unglaublich agile Anwendungsbereitstellung.
• Container sind ressourcenschonend. Es ist einfach und schnell, eine containerisierte Anwendung hochzufahren - viel einfacher und schneller als das Starten eines vollständigen virtuellen Betriebssystems. Gleichzeitig kann eine einzelne Host-Maschine weit mehr Container unterstützen als virtuelle Betriebssysteminstanzen. Aus diesem Grund haben Container noch größere Vorteile als Virtualisierung, wenn es um die Effizienz von Rechenzentren geht.
• Automatisierte Bereitstellung und Verwaltung. Die standardisierte Natur von Containern bedeutet, dass Unternehmen containerisierte Anwendungen dynamisch bereitstellen und verwalten können. Dies wird als Container-Orchestrierung bezeichnet. Orchestrierungswerkzeuge wie Kubernetes automatisieren die Bereitstellung und Überwachung von Anwendungen in großem Umfang.

Die Containerisierung erweitert und verstärkt die Vorteile der Virtualisierung. Unternehmensanwender profitieren von einer noch nie dagewesenen Skalierbarkeit und Verwaltbarkeit, wenn Anwendungen über standardisierte Container bereitgestellt werden.

Die Beziehung zwischen Containern und dem Host

Die Containerisierung bringt erhebliche Vorteile mit sich, insbesondere wenn es sich um groß angelegte Unternehmensanwendungen handelt.

Container verändern jedoch die Art und Weise, wie Anwendungen bereitgestellt werden, grundlegend, und aus praktischer Sicht und auch aus Sicht der Sicherheit ist es hilfreich, die Beziehung zwischen einem Container und seinem Host zu verstehen.

Es stimmt zwar, dass Container isoliert laufen, aber es ist wichtig zu verstehen, dass Container auch Komponenten gemeinsam nutzen. Dadurch entfällt der Overhead, der durch die Ausführung eines separaten Betriebssystems für jede Anwendung in einem Container entsteht.

Das bedeutet auch, dass Container im Vergleich zu einem vollständigen Betriebssystem schneller gestartet werden können. Welche Elemente des Hosts werden also von Containern gemeinsam genutzt? Der Betriebssystem-Kernel ist der wichtigste gemeinsam genutzte Aspekt: Es gibt nur einen laufenden Kernel im Host, und jeder Container im Host teilt sich diesen Kernel.

Als Nächstes werden Treiber und Betriebssystem-Binärdateien von den Containern gemeinsam genutzt, während Container auch den Speicher des Host-Betriebssystems gemeinsam nutzen, obwohl dieser Speicher isoliert ist. Und schließlich teilen sich Container auch die Container-Plattform - wie zum Beispiel Docker.

Die Fähigkeit von Containern, auf diese Weise isoliert zu arbeiten, ist auf einige zentrale Linux-Funktionen zurückzuführen, die von Container-Plattformen (z. B. Docker) verwendet werden, um die Isolierung zu erzwingen. Kernel-Namespaces und cgroups ermöglichen es unabhängigen Containern, sich denselben Linux-Host zu teilen.

Isoliert, ja, aber immer noch verletzlich

Es liegt auf der Hand, dass Container ein hohes Maß an Isolierung bieten, was wiederum ein gewisses Maß an Schutz bietet - Bedrohungen können sich nicht so leicht von einer Anwendung auf eine andere übertragen.

Aufgrund der gemeinsamen Nutzung von Ressourcen, die Container-Workloads inhärent ist, bleiben Container jedoch anfällig - und können tatsächlich neue Schwachstellen einführen, auf die Unternehmen achten müssen. Werfen wir einen Blick auf ein paar Beispiele:

• Image-Sicherheit. Es ist von entscheidender Bedeutung, dass Sie nur Container-Images aus einer vertrauenswürdigen Quelle verwenden. Sowohl ein vergiftetes Image als auch ein ungepatchtes Image können Angriffen Tür und Tor öffnen. Die Sicherheit von Images ist sehr wichtig.
• Sicherheit der Container-Plattform. Wie jede andere Software kann auch Ihre Container-Plattform Sicherheitsrisiken bergen. Denken Sie zum Beispiel an die runC root access remote execution vulnerabilitydie den runC-Bibliotheken innewohnt, die von den Anbietern von Container-Software häufig verwendet werden.
• Risiko derPrivilegienerweiterung. Obwohl Anwendungen theoretisch nicht aus Containern ausbrechen sollten, lohnt es sich, sehr vorsichtig mit den Benutzerprivilegien zu sein, die in einem Container verwendet werden. Wenn eine Container-Anwendung aus irgendeinem Grund Root-Zugriff hat, besteht das Risiko, dass ein Angreifer durch einen Ausbruch Root-Zugriff auf Ihren gesamten Rechner erhält. Das im vorherigen Punkt beschriebene runC-Risiko ist ein typisches Sicherheitsrisiko für einen Ausbruch.

Während Anwendungen also isoliert werden, bringt der Isolationsmechanismus - Container - eigene Sicherheitsrisiken mit sich, und Unternehmen müssen ihre containerisierten Workloads so verwalten, dass diese Sicherheitsrisiken gemindert werden.

Ungepatchte Kernel: Ein verstecktes Container-Sicherheitsrisiko?

Die gemeinsamen Komponenten von Containern führen eindeutig zu Sicherheitsrisiken. Das wohl größte Sicherheitsrisiko für containerisierte Anwendungen ist jedoch der gemeinsam genutzte Betriebssystem-Kernel. Die Sicherheitsrisiken, die der Host-Kernel birgt, sind im Grunde genommen nicht zu erkennen.

Denken Sie daran: Jeder Container in einem Host teilt sich denselben Betriebssystem-Kernel. Es besteht die Gefahr, dass Unternehmen die Isolation und damit die Sicherheitsvorteile der Containerisierung missverstehen, weil sie die Risiken, die ein gemeinsamer Betriebssystemkern mit sich bringt, nicht in Betracht ziehen.

Sobald jedoch der Betriebssystem-Kernel kompromittiert ist, kann auch die Anwendung innerhalb des Containers kompromittiert werden. Und wir wissen, dass Betriebssystem-Kernel seit langem zu Sicherheitslücken aller Art und Größe führen.

Deshalb ist die Kernel-Sicherheit so wichtig, wenn es um die Sicherung von Container-Workloads geht. Es gibt ein paar Dinge, die Sie tun können, um einen sicheren Kernel für Ihre Container-Workloads zu gewährleisten: Seien Sie sich der neuesten Kernel-Sicherheitsrisiken bewusst und stellen Sie sicher, dass Ihr Linux-Kernel nur die Dienste enthält, die Sie für Container-Workloads benötigen.

Vergessen Sie natürlich nicht, den Kernel zu patchen.

Das Problem beim Patchen von Kerneln

Der Linux-Kernel wird kontinuierlich gepatcht. Wenn Schwachstellen auftauchen, passt die Gemeinschaft den Code im Linux-Kernel an, um diese Schwachstellen zu bekämpfen - und veröffentlicht einen Patch. Nicht gepatchte Systeme sind gefährdet, gepatchte Systeme nicht.

Patchen sollte ein Selbstläufer sein: Es ist eine einfache Sicherheitsmaßnahme, die die Sicherheit Ihrer Container erheblich erhöht. Doch konsequentes Patchen kann sehr schwierig sein:

• Patching ist zeitaufwändig. Angesichts der Menge an Linux-Kernel-Patches, die veröffentlicht werden, ist es für viele Unternehmen schwierig, mit dem Patching Schritt zu halten - insbesondere bei großen Technologieparks mit Tausenden von Rechnern.
• Konsistentes Patching ist teuer. Wenn sie nicht automatisiert werden, kann die Bereitstellung von Patches selbst die Ressourcen der besten technischen Teams aufzehren. Patching wird zu einem teuren Prozess und zu einem leichten Ziel für Einsparungen und Kostensenkungen.
• Patches sind störend. Ein Kernel-Patch erfordert häufig einen Neustart des Servers. Für viele Workloads ist ein Neustart äußerst störend. Der Neustart eines Containers kann sehr schnell sein - der Neustart des gesamten Hosts kann zu einer spürbaren Dienstunterbrechung führen. Infolgedessen werden Patches oft verzögert.

Es liegt auf der Hand, dass eines der größten Sicherheitsrisiken für containerisierte Workloads in der Tat sehr schwer konsequent zu verwalten ist.

KernelCare Live-Patching-Integration

Die Patching-Automatisierung ist der erste Schritt, um die Risiken von Kernel-Schwachstellen unter containerisierten Workloads erfolgreich zu reduzieren. Ein weiterer wichtiger Schritt ist das Live-Kernel-Patching: die Möglichkeit, den Betriebssystemkern zu aktualisieren, ohne dass ein Server-Neustart erforderlich ist. KernelCare Live-Patching bietet beides.

Unternehmen, die containerisierte Workloads verwalten, können mit KernelCare sicherstellen, dass die Kernel in ihren Container-Hosts konsistent und ohne Unterbrechung gepatcht werden. Dies ist ganz einfach: Installieren Sie KernelCare einfach wie gewohnt.

Wenn Sie Ihre Container-Hosts mit KernelCare patchen, profitieren Sie folglich auch von einem vollautomatischen Patching des Kernels, der von den Containern verwendet wird. Da Container den Kernel des Hosts gemeinsam nutzen, müssen Sie KernelCare nur einmal auf Ihrem Container-Host installieren - und die Kernel-Updates gelten dann für alle Container auf diesem Host.

Kurz gesagt: KernelCare ist ein effizienter und praktischer Weg, eines der größten Sicherheitsrisiken im Zusammenhang mit der Containerisierung zu bewältigen.

Weitere Tipps für die Sicherheit des Container-Kernels

Bevor wir den Artikel abschließen, wollen wir noch ein paar andere Punkte ansprechen, die bei der Sicherung des Kernels Ihres Container-Hosts zu beachten sind. Ja, Patches sind wichtig, aber Sie sollten auch die folgenden Punkte berücksichtigen - die meisten davon sind einfach nur gute Praxis für die Serversicherheit:

• Entfernen Sieden Root-Benutzer. Durch die Einschränkung des Root-Benutzers können Sie sicherstellen, dass ein Container, der aus der Isolation ausbricht, nicht automatisch Root-Zugriff auf den gesamten Server erhält.
• Begrenzen Sie die von Ihnen ausgeführten Kernel-Module. Wenn Sie einen Server einrichten, können Sie ihn durch Hinzufügen von Kernel-Modulen erweitern. Um ein Maximum an Sicherheit zu gewährleisten, empfehlen wir Ihnen, nur so viele Kernel-Module zu installieren, wie Sie für Ihre Container-Umgebung benötigen - stellen Sie jedoch sicher, dass Sie kritische Module behalten, die die Sicherheit über Rollen und Berechtigungen hinweg durchsetzen.
• Nutzen Sie Container-Sicherheits-Tools. Es gibt Tools, die speziell dafür entwickelt wurden, Ihre Containerkonfiguration zu scannen und mit den Best Practices abzugleichen. docker-bench-security ist ein Beispiel dafür, es prüft Dutzende von Punkten in Ihrer Konfiguration und bewertet sie nach den Best Practice-Regeln.

Wie immer erfordert eine umfassende Sicherheit eine sorgfältige Serverkonfiguration und eine kontinuierliche, proaktive Serververwaltung.

Schlussfolgerung

Die Containerisierung verändert die Arbeitslasten von Unternehmensanwendungen, indem sie die Kosten für die Infrastruktur senkt, die Einführung von Anwendungen beschleunigt und eine noch nie dagewesene Flexibilität und Skalierbarkeit ermöglicht.

Die Ausführung von Anwendungen innerhalb von Containern birgt jedoch auch einzigartige Sicherheitsrisiken, die möglicherweise nicht sofort ersichtlich sind. Kernel-Sicherheit und Patching sind ein kritischer Bereich, der mit großer Sorgfalt behandelt werden muss.

KernelCare gibt Ihrem Unternehmen die Möglichkeit, die Kernel, die Ihre containerisierten Workloads unterstützen, automatisch zu aktualisieren, und zwar ohne die mit Systemneustarts verbundenen Unterbrechungen und Ausfallzeiten.