Mit einer vernünftigen Backup-Strategie wappnen sich Administratoren erfolgreich gegen Datenverluste und längere Systemausfälle. So zeigen wir Ihnen ... (mehr)

Problematische Docker-Images

Ging es in diesem Artikel bisher hauptsächlich darum, die diversen Schutzmauern vorzustellen, mit denen Docker eine Container-Isolierung vornimmt, möchten wir an dieser Stelle noch kurz ein grundlegendes Problem in der Art und Weise, wie Docker mit Images umgeht, in das Bewusstsein der Leser rücken.

Docker arbeitet mit Containern, die auf Basis von zuvor erstellten Images erzeugt werden. Diese Images können Sie entweder selbst generieren oder von sogenannten Registry-Servern herunterladen. Standardmäßig greift Docker auf den öffentlichen Server »index.docker.io« zurück, welcher sich mittels »docker search« durchsuchen lässt und von dem Sie mittels »docker pull« schließlich das gewünschte Image herunterladen können. Das Problem hierbei ist, dass ein »docker pull« nicht nur das gewünschte Image herunterlädt, sondern es gleichzeitig auch entpackt und verarbeitet. An dieser Stelle müssen Sie also darauf vertrauen, dass das heruntergeladene Image auf Ihrem System keinen Schaden anrichten möchte. Das wäre fatal, besonders dann, wenn das Image mit dem Tool xz verpackt wurde. Anders als bei Images, die mit bz2 oder gzip komprimiert wurden, greift das in der Programmiersprache Go geschriebene docker-Kommandozeilentool nämlich nicht auf die Go-internen Bibliotheken zum Entpacken des Images zurück, sondern ruft einfach das in C geschriebene Binär-Programm xz auf.

Dass der Vorgang im Benutzerkontext Root stattfindet, verschlimmert das Ganze noch. In den letzten Releases von Docker wurde zwar versucht, eine Verifikation von Images einzuführen, leider gibt es hier aber noch einige Schwachstellen, sodass Sie sich zum aktuellen Zeitpunkt noch nicht auf diese Funktion verlassen sollten. Die einzige sichere Variante besteht aktuell einfach darin, Images lediglich aus vertrauenswürdigen Quellen zu beziehen, indem Sie beim Import die gewünschte Registry einfach mit übergeben:

# docker pull registry.somewhere.com/image

Die Angabe der Registry funktioniert übrigens auch aus Dockerfiles heraus. Viele Distributoren bieten aktuell ihre Images auch zum Download an, sodass Sie diese über einen sicheren Kanal beziehen können und schließlich mittels "docker load" auf Ihrem System hinzufügen. Für Fedora finden Sie aktuelle Docker-Images beispielsweise unter [2].

Privilegierte Container

Zum Schluss sei noch darauf hingewiesen, dass sich all die Sicherheitsmaßnahmen, von denen Sie bisher in diesem Artikel gelesen haben, bei Bedarf auch abschalten oder lockern lassen. Warum, werden Sie sich sicherlich an dieser Stelle fragen. Die Antwort auf diese Frage ist jedoch recht leicht. Stellen Sie sich vor, Sie wollen einen Container betreiben, in dem ein bestimmter System-Management Dienst, ein Monitoring-Tool oder ein Log-Server laufen. Solche Applikationen brauchen in den allermeisten Fällen wesentlich mehr Zugriffe auf das Host-System, als Docker üblicherweise zugestehen würde. Mit herkömmlichen Containern ist dies nicht möglich, daher gibt es nun die Möglichkeit, sogenannte Super Privileged Container (SPC) zu erzeugen, um in diesen jede beliebige Art von Software installieren zu können. Solche Container haben nahezu kompletten Zugriff auf das Host-System und benötigen lediglich den Mount-Namespace zum Betrieb. Alle anderen Namespaces können Sie beim Starten des Containers bei Bedarf abschalten. Der Container hat daher Zugriff auf das Netzwerk des Hosts und sieht auch die Prozesse des Hosts. Einen solchen Container starten Sie dann beispielsweise mit dem folgenden Befehl:

# docker run --name myspc --privileged --net=host --pid=host --ipc=host fedora:latest <app>

Welche Namespaces Sie dabei deaktivieren wollen, hängt ganz davon ab, welche Applikation Sie letztlich in Ihrem Container betreiben wollen und welche Zugriffe diese benötigt. Weitere Informationen zu solch privilegierten Containtern finden Sie in der Manpage von »docker-run« .

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite