© Sergiy Tryapitsyn, 123RF

Das Thema Container- und Kubernetes-Security ist komplex, und manche Admins scheitern selbst an seinen eher einfachen Aspekten. Das Linux-Magazin zeigt, wie man die zehn häufigsten Fehler vermeidet.

Das Thema Sicherheit gehört zum täglichen Brot jedes Mitarbeiters im IT-Umfeld. Zu hoch ist der Einsatz, falls mal etwas schief geht: Weisen die Datenschutzbehörden der Länder Firmen nach, dass Daten verloren gingen, weil marktübliche Maßnahmen zu ihrem Schutz nicht umgesetzt wurden, wird das sehr schnell sehr teuer. Kein Wunder also, dass das Thema allerorten hoch im Kurs steht. Es greift auch im Container-Kontext: Ganz gleich, ob man einzelne Container betreibt oder den Flottenorchestrierer Kubernetes einsetzt – den Sicherheitsaspekt dieser Lösungen lässt der Admin besser nicht außer Acht.

Zwar scheint es vielerorts so, als hätten Container die klassischen Werkzeuge der IT längst abgelöst und seien ubiquitär, doch der Eindruck täuscht. Auch heute begegnen selbst erfahrene Admins jeden Tag Containern zum ersten Mal. Und wie das mit neuen Technologien so ist, herrscht anfangs Unsicherheit im Hinblick auf die Faktoren, die es in Sachen Sicherheit bei Containern zu beachten gilt. Selbst erfahrene Container-Jockeys langen noch immer regelmäßig daneben, wenn es um das Thema Container-Sicherheit geht.

Dieser Artikel geht im Detail auf das Thema Container-Sicherheit ein. Er behandelt dabei die Themenkomplexe Container und Kubernetes separat und stellt für beide die fünf typischen Fehler vor, die Admins in Sachen Sicherheit regelmäßig machen. Das soll Ihnen eine deutlich bessere Vorstellung davon vermitteln, worauf Sie bei bestehenden und neuen Container-Setups achten müssen, um die eigene Angriffsfläche so gut wie möglich zu verkleinern.

Container: fehlende Zugriffskontrolle, privilegierte Container

Nahezu jeder Admin hat ein gewisses Gefühl dafür, dass Dienste nach Möglichkeit nicht mit den Rechten des Systemadministrators Root laufen sollten. Allerlei Tricks und Kniffe haben sich die Autoren von Software in den vergangenen Jahren überlegt, um daraus resultierende Probleme zu vermeiden – seien es Chroot-Umgebungen, Namespaces, Cgroups oder mittlerweile auch der Lockdown-Modus für den Kernel. Völlig arglos indes betreiben viele Administratoren ihre Container ohne jeden Schutzzaun und im privilegierten Modus. Der heißt so, weil er dem Container beliebige Zugriffsrechte auf die Ressourcen des Systems einräumt, was der Nutzer Root im Container dem des Systems in Sachen Berechtigungen praktisch gleichstellt.

Wer noch das klassische Docker verwendet und nicht das neuere Podman, der betreibt heute zudem den Docker-Daemon regelmäßig mit den Berechtigungen von Root, ohne das überhaupt zu merken. Dabei ist das längst nicht mehr notwendig: Docker kann den eigenen Daemon bereits seit vielen Jahren auch ohne die Rechte des Systemadministrators laufen lassen, wofür der Rootless Mode zuständig ist. Vor dem Hintergrund eines modernen Security-Konzepts stellt dieser Modus das grundlegende Pflichtprogramm dar, um Docker abzudichten. Ferner hilft Mandatory Access Control per SELinux oder AppArmor dabei, den Übergriff von Software in Containern auf andere Systemressourcen zu verhindern, falls die Grenzen des Containers einmal aufweichen (Abbildung 1)

Abbildung 1: Mandatory Access Control, wie hier per AppArmor, hilft auf Hosts, Container voneinander abzuschirmen und sicherer zu gestalten.

Auch für Container gilt: Der privilegierte Modus verbietet sich von selbst, wenn es für ihn nicht extrem gute Gründe gibt. Das “extrem” sollte man in diesem Kontext wirklich ernst nehmen, denn selbst Begründungen, die früher noch gegolten hätten, treffen heute nicht mehr zu. Beispielsweise braucht kein Programm – und mithin auch kein Container – mehr Root-Rechte, um privilegierte Ports zu binden. Das lässt sich stattdessen per Capability erledigen und ist in Docker wie in Podman auch so eingebaut.

Container: konventionelle Security-Konzepte taugen nicht

Ein weiterer umfassender Themenkomplex in Sachen Container und Sicherheit betrifft das Anwenden bestehender Security- und Compliance-Konzepte auf Container und ihre Orchestrierer. Jeder Admin kennt das: Im Unternehmen gibt es Dutzende unterschiedliche, historisch gewachsene Regelwerke mit Vorgaben, wie Security und Compliance auf Systemen zu funktionieren haben. Die meisten davon ergeben durchaus Sinn. Regelmäßig sind die Konzepte jedoch auf konventionelle Umgebungen ausgelegt und sehen Container gar nicht vor. Das führt zu seltsamen Effekten.

Ein Beispiel ist das Thema Software Defined Networking (SDN). Viele Firmen planen ihre Umgebung in Form einzelner Setups, die sich netzwerkseitig in verschiedene Segmente unterteilen. Das klappt bei Containern schon dann nicht sinnvoll, wenn diese mittels Orchestrierer über unterschiedliche Hosts verteilt sind. In solchen Setups kommen regelmäßig SDN-Lösungen zum Einsatz, die diverse Annahmen klassischer Netzwerkdesigns ad absurdum führen.

Während Admins in klassischen Umgebungen für bestimmte Services manchmal sogar eigene Netzwerksegmente bauen und per Firewall separat absichern, befinden sich in Container-Umgebungen regelmäßig alle Dienste im selben logischen Netzwerk. Die Annahme, dass das lokale Netz sicher sei, trifft in einer solchen Umgebung nicht zu. Hier ist allerdings weniger der Admin gefragt als der Entwickler: Wer eine virtuelle Umgebung aus verschiedenen Containern konstruiert, sollte tunlichst Werkzeuge wie Istio verwenden, um innerhalb der Umgebung Sicherheitsschranken einzuziehen. Das macht zwar mehr Mühe, führt aber zu einem angenehmen Nebeneffekt: Istio kann beispielsweise die Verbindungen zwischen den Diensten gleich auch automatisch mit SSL-Verschlüsselung versorgen. Das macht es schwieriger, Informationen von außen abzufischen.

Dafür, dass viele konventionelle Security-Ansätze in Container-Umgebungen gar nicht oder nur bedingt taugen, ließen sich zahllose weitere Beispiele nennen. Dabei spielt freilich auch eine Rolle, welche Maßnahmen der Admin üblicherweise zu seinem Standardrepertoire zählt. Die Schlussfolgerung für diesen Punkt lautet deshalb: Noch bevor der Admin mit dem Deployment von Containern anfängt, sollte er ein speziell darauf zugeschnittenes Sicherheitskonzept ausarbeiten. Zwar wird es in vielen Fällen aufwendig sein, die Anforderungen der Container-Technik mit bestehenden Security- und Compliance-Vorschriften unter einen Hut zu bekommen, doch nur so gelingt am Ende ein gutes Konzept.

Container: Missachten des Hosts, der Container betreibt

Manche Administratoren widmen dem Thema Container-Sicherheit kaum Aufmerksamkeit, andere kümmern sich ausschließlich darum – und vergessen, dass unter den Containern ja auch noch ein Host läuft (Abbildung 2). Der ist heute in den meisten Fällen mit Linux ausgestattet, oft allerdings mit einem sehr reduzierten. Seine Hauptaufgabe besteht darin, das Container-Framework zu betreiben. Admins tun gut daran, die Hosts in ihren Setups nicht zu vergessen und die Sicherheitsmechanismen zu nutzen, die die jeweiligen Distributoren anbieten. Dazu gehört etwa, auf das regelmäßige Einspielen von Sicherheitsaktualisierungen zu achten. Ein SSH-Daemon, der zum »rootshelld« mutiert, stellt schließlich auch unter CoreOS ein Problem dar.

Abbildung 2: Virtualisierung – wie hier per KVM – erfordert auch, die Hosts vor unerlaubten Zugriffen gut zu schützen, etwa durch MAC und Kernel-Funktionen.

Andere Mechanismen spielen ebenfalls eine Rolle, etwa Mandatory Access Control (MAC), auch unter den Namen SELinux und AppArmor bekannt. Viele Admins haben bis heute von SELinux und Apparmor keine sonderlich hohe Meinung, nicht zuletzt, weil sich die Werkzeuge regelmäßig als die Bösewichte entpuppen, wenn einmal etwas nicht so funktioniert wie gewünscht. Sie einfach auszuschalten, ist grundsätzlich aber keine gute Idee, denn sowohl SELinux als auch AppArmor haben das Potenzial, vor allem für Systemdienste als letzte Bastion zu dienen, falls alle anderen Mechanismen versagen.

Zur Erinnerung: Container sind ja letztlich auch nur eine Kombination aus Namespaces, Cgroups und weiteren Features des Linux-Kernels. Sie bilden im Kernel eine Barriere. Gibt es einen Bug, ist diese Barriere schlimmstenfalls nutzlos und komplett durchlässig. Da schadet es nicht, wenn es Angreifern trotzdem nicht möglich ist, auf sämtliche Systemressourcen zuzugreifen. Aktuelle Sicherheitsanalysen von diversen Forschern bestätigen das: Danach ereignet sich ein großer Teil der Angriffe in IT-Umgebungen, indem ein Angreifer zunächst ein einzelnes System unter seine Kontrolle bringt und sich von dort intern weiterhangelt. Hält der Admin seine Compute-Hosts aktuell und zieht zusätzliche Schranken ein, erhöht er aktiv die Sicherheit seiner Umgebung.

Container: nicht auf den Provider verlassen

Bei vielen Admins setzt sich im Container-Kontext ein fataler Irrglaube fest: Der Irrglaube nämlich, dass es okay sei, sich um die Sicherheit der Software in Containern nicht zu kümmern, wenn diese auf den Container-Abbildern der Hersteller basieren. Das führt regelmäßig dazu, dass Entwickler einmal ein Container-Abbild aus dem Netz besorgen und ihre Umgebung darauf aufbauen, es selbst aber nicht mehr aktualisieren. Klar ist jedoch: Wie das Host-System enthalten auch Container Software, die löchrig sein oder werden kann. Der Admin muss deshalb unbedingt die Sicherheit der Komponenten in seinen Containern beobachten. Und längst nicht jeder Anbieter stellt sofort neue Abbilder bereit, wenn ein Bug mit Sicherheitsbezug auftaucht. Hier spielt auch das Blackbox-Problem eine Rolle, das am Ende des Artikels noch ausführlich zur Sprache kommt.

Container: Aufräumen ist Pflicht

So mancher Admin kennt das Problem: Während man dabei ist, eine Anwendung oder eine virtuelle Umgebung zu entwickeln, unternimmt man viele Tests und arbeitet dabei mit eigens für diesen Zweck hergestellten Testinstanzen – dagegen ist grundsätzlich auch nichts einzuwenden.

Die Zahl der Admins, die am Ende vergessen, die Testinstanzen zu löschen oder wenigstens abzuschalten, ist aber erschreckend hoch, mit fatalen Folgen: Lange Zeit gammeln die Test-Container unbemerkt vor sich hin, oft sogar mit öffentlichen IP-Adressen versehen. Außer dem Admin weiß oft niemand, dass sie überhaupt existieren. Sie kommen in keinem Monitoring vor, fallen beim Einspielen von Sicherheitsaktualisierungen unter den Tisch und sind in diesem Sinne typische U-Boote.

Angreifer indes, die andere Systeme schematisch nach Lücken abscannen, finden den Sperrmüll. Deshalb gilt: Wer testet und experimentiert, räumt am Ende besser seine Überbleibsel weg.

Kubernetes: immer langsam mit den Pferden

Ein regelmäßig auftretendes Sicherheitsproblem bei Containern ist so banal, dass es fast überflüssig erscheint, es hier aufzuführen – aber eben nur fast. Viele Firmen stürzen sich Hals über Kopf und mit viel Enthusiasmus in das Container-Thema. Sie erzeugen in kürzester Zeit eine virtuelle Umgebung auf Basis von Anleitungen und fertigen Templates aus dem Netz. Ohne sich mit Kubernetes, Container-Technologien oder Tools wie Rook [1] oder Istio ausführlich beschäftigt zu haben, nehmen sie das Setup im Anschluss in Betrieb.

Wer aber nicht weiß, welche Herausforderungen etwa Kubernetes im Container-Kontext mit sich bringt, kann darauf auch nicht reagieren. Die Zeit, die für das Erdenken eines sinnvollen Sicherheitskonzepts nötig wäre, fällt in diesem Arbeitsmodus zudem regelmäßig unter den Tisch. Schneller als sein Schatten schießt im Idealfall nur Lucky Luke. Admins sollten ein neues, virtuelles Setup mit Vorsicht planen und erst in Betrieb nehmen, wenn sie wissen, was sie tun.

Kubernetes: nur K8s ist nicht gut genug

Einige Male kam dieser Aspekt im Artikel bereits implizit zur Sprache, er sei im Kubernetes-Kontext aber auch nochmals explizit hervorgehoben: Sicherheit ist im Idealfall ein holistischer Ansatz. Der Admin kümmert sich also nicht nur darum, einzelne Container oder das System abzusichern, dass seine Container betreibt, sondern auch darum, wie sich Sicherheit im Kontext des gesamten Systems auswirkt.

Das geht schon bei der genutzten Kubernetes-Distribution los. Zwar folgen die Hersteller hier verschiedenen Ansätzen, um ihre Distributionen – OpenShift, Rancher und dergleichen mehr – einigermaßen gut zu sichern. In der Standardkonfiguration gibt es aber trotzdem viele Hebel und Schalter, die für generische Setups aktiv sein müssen, im konkreten Einzelfall aber nicht. Muss die Kubernetes-API etwa nach außen hin exponiert sein? Falls nein, genügt vielleicht eine interne IP-Adresse, was den Angriffsvektor reduziert.

Das zuvor bereits erwähnte Security-Konzept, das der Admin im Kubernetes-Kontext für sein Setup besser erstellt, sollte alle Teile der Installation umfassen. Die Systeme, auf denen die Kubernetes-Basiskomponenten laufen und die Admins ganz oft geflissentlich ignorieren, gehören ebenso zum Konzept wie die Nodes mit den eigentlichen Containern. Diese gilt es, wie beschrieben ebenfalls gesondert im Hinblick auf ihre Sicherheit zu betrachten.

Freilich spielt hier auch eine Rolle, ob es sich um ein Multi-Tenant-Setup handelt oder ob im System nur ein einzelner Kunde unterwegs ist. Generell eignet sich Kubernetes ab Werk nicht sonderlich gut für Multi-Tenant-Umgebungen, weil das eine Reihe zusätzlicher Implikationen mit sich bringt. Auch das sollte der Admin bei der Planung seines Setups beachten. Besser ist es, unterschiedliche Kunden mit eigenen Kubernetes-Instanzen zu versorgen. Das lässt sich leichter realisieren, wenn ohnehin eine Virtualisierungsumgebung zur Verfügung steht, auf der sich VMs schnell starten lassen.

Doch Vorsicht: Das Prinzip des Sicherheitsholismus gilt auch hier. Kein Mensch hat etwas davon, wenn Angreifer die VMs oder gar die Hosts mit den VMs übernehmen, in denen auf oberster Ebene ein Kubernetes läuft. Immerhin: Die zuvor schon erwähnten klassischen Security-Konzepte der Unternehmen lassen sich auf den Hosts zumindest gut anwenden.

Kubernetes: Neue Räder sind nicht runder

Das nächste typische Sicherheitsproblem, das in vielen Kubernetes-Umgebungen auftritt, spielt sich nicht so sehr auf der Konfigurationsebene ab, sondern vielmehr auf der Ebene der Entwicklung von Anwendungen. Die Rede ist vom Not-invented-here-Syndrom: Viele Entwickler und Administratoren neigen dazu, Features, die es in Kubernetes bereits nativ gibt oder die sich zumindest über externe Funktionen nachrüsten lassen, lieber selbst nachzubauen.

Ein typisches Beispiel sind Load-Balancer. Container-Anwendungen fußen oft auf den Prinzipien des Cloud-Native-Computings. Dazu gehört wiederum die Idee der Microservices als zentralem Designelement. Wenn es von einem Service beliebig viele Instanzen gibt, auf die es die anstehende Arbeit zu verteilen gilt, bedeutet das aber auch: Es muss eine Stelle im Setup geben, die diese Verteilung vornimmt. “Hurra, ein Load-Balancer”, denkt sich mancher Anwendungsentwickler nun und schreitet sogleich zur Tat, um einen Container mit HAProxy oder Nginx zu bauen, den er seinen anderen Pods künftig zur Seite stellt.

Was wie eine gute Idee klingt, entpuppt sich bei genauerem Hinsehen jedoch als unbequem und potenziell gefährlich. Denn das Thema Load Balancing ist in virtuellen Umgebungen, die aus Containern bestehen, längst umfassend gelöst. Istio bietet vollständiges Load Balancing zwischen sämtlichen Instanzen einer Umgebung, lässt sich dabei aber als native Ressource in Kubernetes verwenden. Am Ende laufen die Komponenten von Istio freilich auch in eigenen Containern, doch der Entwickler muss sich nicht darum kümmern, dass sie entsprechend konfiguriert sind – das erfolgt über die Definition der Ressourcen in Kubernetes.

Ebenso ist der Austausch von Istio-Instanzen keine große Sache: Istio selbst stellt dafür Bordmittel zur Verfügung (Abbildung 3). Sobald die Entwickler hinter Istio also ein Sicherheitsupdate veröffentlichen, spielt der Admin den neuen Container ein, und die Sache hat sich. Load-Balancer Marke Eigenbau hingegen benötigen mehr Pflege, weil der Administrator hier auch das Basis-Image pflegen und sicher halten muss, auf dem der Load-Balancer basiert. Hinzu kommt, dass Istio durch eine riesige Community unterstützt wird, die regelmäßig auch das Thema Sicherheit im Auge hat. Für ein einzelnes Abbild mit Nginx oder HAProxy zeichnet der Admin jedoch selbst verantwortlich.

Abbildung 3: Werkzeuge wie Istio kümmern sich um Themen wie Load Balancing ganz automatisch, sodass der Admin das Rad nicht neu zu erfinden braucht (Grafik: Istio).

Das Load-Balancer-Beispiel ist freilich nur eines von vielen. Mancher Entwickler versteigt sich im Eifer des Gefechts sogar dazu, sich ein Ceph in Containern selbst nachzubauen, obgleich es das in Form von Rook längst gibt. Solche Anflüge kosten nicht nur viel Mühe, sie verschlingen auch unverhältnismäßig viele Ressourcen. Die dringende Empfehlung lautet deshalb: Bevor man das Basteln beginnt, schaut man besser einmal nach, ob andere Kubernetes-Nutzer nicht bereits vor demselben Problem standen und es schon gelöst haben.

Kubernetes: Auch die API gehört geschützt

Dass Container und Deployments innerhalb von Kubernetes geschützt werden müssen, hat dieser Artikel mittlerweile verdeutlicht. Viele Admins leisten sich jedoch einen Lapsus in Sachen Sicherheit, der mit den Containern selbst gar nicht viel zu tun hat: Sie ignorieren die Kubernetes-API als potenzielles Einfallstor und lassen sie weitgehend außen vor. Das rächt sich im schlimmsten Falle bitter.

Es gibt mehrere Möglichkeiten, den Zugriff auf die Kubernetes-API zu beschränken (Abbildung 4). Sinnvoll ist es, mit Benutzern und Rollen zu arbeiten und für diese starke Passwörter zu verwenden. Grundsätzlich lassen sich in Kubernetes aber auch Tokens verwenden, etwa für Service-Accounts. Und potenziell lässt Kubernetes sich sogar völlig ohne Benutzerverwaltung betreiben. Hängt eine solche Kubernetes-API aber frei im Netz, öffnet das einem Missbrauch Tür und Tor.

Abbildung 4: Die Kubernetes-API lässt sich über eine Reihe von Maßnahmen mit zusätzlichen Sicherheitsbarrieren versehen – das ist dringend angeraten. Quelle: Kubernetes

Ein solches Szenario gilt es aus Sicht des Admins also unbedingt zu vermeiden, der Betrieb ohne Absicherung über Benutzerzugänge verbietet sich deshalb ganz von allein. Ein weiteres No-go ist unverschlüsselte Kommunikation von Clients mit der Kubernetes-API: Diese sollte man unbedingt mit einem SSL-Zertifikat versehen, damit sich Benutzernamen und Passwörter nicht abfischen lassen. Die Passwörter für Service-Accounts sollte der Admin zusätzlich so wählen, dass man sie nicht ohne Weiteres erraten kann.

Kubernetes: das Blackbox-Problem

Den letzten Bock im Kontext der Kubernetes-Security hat dieser Artikel sich bis ganz zum Schluss aufgehoben. Es geht um eine Unart, die sich mit Containern und Kubernetes in der IT breitgemacht hat und die immer noch stark um sich greift.

Container bringen im Idealfall sämtliche Software-Komponenten mit, die sie brauchen. Anders als bei den Paketen der klassischen Linux-Distributionen muss der Admin sich hier also nicht mit Abhängigkeiten befassen. Mehr noch: Er kann den Container so bauen und vorbereiten, dass er sich auf beliebigen Systemen mit Container-Laufzeitumgebung ausführen lässt. Was in der Theorie toll klingt, wird in der Praxis schnell zum Problem – vor allem in Sachen Sicherheit. Der Ansatz “Works inside VirtualBox on my MacBook Air” ist für den produktiven Einsatz im IT-Alltag schlicht nicht gut genug – aus mehreren Gründen.

Einerseits ist ein Container, den ein Nutzer sich irgendwo aus dem Netz fischt und betreibt, für den Nutzer selbst eine komplette Blackbox. Das gilt besonders für jene Container, deren Quellen die Entwickler nicht offenlegen. Entsprechend soll es nicht wenige Einfaltspinsel geben, die ihre Kubernetes-Umgebung unfreiwillig zum hyperaktiven Bitcoin-Miner umfunktioniert haben, weil sie Container-Images irgendwo aus den Untiefen des Internets genutzt haben.

Doch nicht nur manipulierte Abbilder sind ein Problem: Wenn einmal etwas schiefgeht und der Admin ein Update für einen Container braucht, kann er das bei den Abbildern Dritter (Abbildung 5) nicht selbst erstellen. Er muss sich stattdessen darauf verlassen, zeitnah vom ursprünglichen Autor ein neues Abbild zu bekommen – etwa wenn im Container eine Komponente verbaut ist, für die eine Sicherheitswarnung vorliegt. Der gesamte Ansatz verbietet sich daher.

Abbildung 5: Inoffizielle Docker-Abbilder sind nicht automatisch schlecht, doch sollte der Admin idealerweise bevorzugt auf eigene Images aus CI/CD-Produktion setzen.

Wer Container in Carrier-Qualität betreiben möchte, der braucht eine eigene CI/CD-Pipeline. Die muss in der Lage sein, jeden benötigten Container in der Firma zu jeder Zeit automatisch neu zu bauen, sobald ein Entwickler eine Änderung am Quelltext des Containers vornimmt und diese einpflegt. Wie so oft empfiehlt sich Git als Werkzeug der Wahl, zumal gängige Git-Repositories wie Github oder Gitlab eigene CI/CD-Systeme haben, die auch fertige Container produzieren können. Wer stattdessen eine eigene Pipeline etwa auf Basis von Jenkins bauen möchte, kann das freilich ebenso gut tun.

Wichtig ist nur, dass der Administrator es tut und sich nicht auf die Arbeit Dritter verlässt. Eine Ausnahme von dieser Regel bilden freilich die offiziellen Container-Images der Distributoren sowie der Hersteller von Programmen, bei denen stets auch die Abbildquellen veröffentlicht werden.

Fazit

Nach der Erfahrung des Autors spielen sich die allermeisten Probleme im Kontext von Containern und Sicherheit auf Basis zweier Faktoren ab.

Einerseits verlassen sich Admins zu sehr auf die Sicherheitsmaßnahmen, die sie von konventionellen Umgebungen kennen. Dabei ignorieren sie, dass viele dieser Maßnahmen bei Containern gar keine Wirkung entfalten und sich in einigen Fällen auch nicht komplett identisch umsetzen lassen (etwa VLANs, die bei Containern wegen SDN oft genug keine Rolle mehr spielen).

Das zweite Hauptproblem liegt darin, dass man sich zu sehr auf die Defaults verlässt, die andere vorgeben: Ein frisches Kubernetes schießt in Sachen Security so manchen Bock, und eine Docker-Standard-Installation betreibt die Container noch immer im privilegierten Modus. Das ist für Sicherheit im Jahr 2020 einfach nicht gut genug.

Ja, Container erweitern die Aufgaben des Admins, weil er sich um eine zusätzliche Fehlerdomäne beim Themenkomplex Sicherheit zu kümmern hat. Das ist allerdings ein Teil des Deals: Wer Container und Kubernetes nutzen will, holt sich diese Thematik ins Setup – ob er will oder nicht. (jcb)