Im Moment gibt es keine Möglichkeit, einfach herauszufinden, ob bestimmten Docker-Containern vertraut werden soll. Es gibt Basiscontainer von Docker- und Betriebssystemanbietern, die sie als "vertrauenswürdig" bezeichnen, aber der Software fehlen noch gute Mechanismen (z. B. digitale Signatur), um zu überprüfen, ob Bilder nicht manipuliert wurden.

Zur Verdeutlichung an Zitieren Sie den kürzlich veröffentlichten CIS-Sicherheitsstandard für Docker in Abschnitt 4.2.

Offizielle Repositorys sind Docker-Images, die von der Docker-Community oder dem Anbieter kuratiert und optimiert wurden. Die Signier- und Überprüfungsfunktion für Docker-Container-Images ist jedoch noch nicht bereit.

Daher überprüft die Docker-Engine die Herkunft der Containerbilder nicht selbst.

Sie sollten daher beim Abrufen von Containerbildern große Vorsicht walten lassen.

Wenn Sie vom Docker-Hub aus in die Welt der allgemeinen Container von Drittanbietern einsteigen, ist das Bild noch schwieriger. AFAIK Docker führt keine Überprüfung der Containerdateien anderer Personen durch, daher gibt es eine Reihe potenzieller Probleme.

• Der Container enthält tatsächliche Malware. Ist das wahrscheinlich, weiß niemand. Ist es möglich, ja.
• Der Container enthält unsichere Software. Docker-Dateien sind im Grunde wie Batch-Skripte, die eine Maschine erstellen. Ich habe einige gesehen, die beispielsweise Dateien über unverschlüsselte HTTP-Verbindungen herunterladen und sie dann als root im Container ausführen. Für mich ist das kein guter Weg, um einen sicheren Container zu erhalten.
• Der Container legt unsichere Einstellungen fest. Bei Docker geht es darum, die Einrichtung von Software zu automatisieren. Dies bedeutet, dass Sie in gewissem Maße darauf vertrauen, dass alle Personen, die die Docker-Dateien erstellt haben, diese so sicher konfiguriert haben, wie Sie es gerne hätten.

Natürlich könnten Sie alle Docker-Dateien prüfen, aber wenn Sie dies getan haben, wäre es fast besser gewesen, das Ding selbst zu konfigurieren!

Ich fürchte, dass dies eine Entscheidung ist, die nur Sie wirklich treffen können. Sie tauschen die für die Entwicklung und Pflege Ihrer eigenen Images erforderliche Zeit gegen das erhöhte Risiko aus, dass jemand, der an der Produktion der von Ihnen heruntergeladenen Software beteiligt ist, böswillig ist oder einen Fehler in Bezug auf die Sicherheit des Systems gemacht hat.

Vertrauen Sie ihm genauso wie jedem nicht signierten Code, den Sie auf Ihren Systemen ausführen. Container sind nur Prozesse mit einigen zusätzlichen Namespace-Schutzfunktionen. Das sind also alle Schutzfunktionen, die sie erhalten. Sie sprechen immer noch mit demselben Kernel darunter.

Es ist am besten, einen Docker-Container als das Ausführen einer Anwendung auf dem Hostsystem zu betrachten. Es gibt einige Versuche, den Docker-Daemon durch Entfernen der Linux-Kernel-Funktionen zu sperren, dies ist jedoch keine Garantie. Wenn Sie Docker ausführen, können Sie einige Maßnahmen ergreifen, um dieses Risiko zu verringern.

Im Wesentlichen ist es die gleiche Frage, ob Open Source-Software vertrauenswürdig ist. Ich denke jedoch, dass das Risiko der Verwendung von Community Docker-Containern derzeit etwas höher ist als das Risiko der Verwendung von Open Source-Software.

Erstens gibt es, wie Sie bereits erwähnt haben, keine Signierung und Überprüfung jetzt. Gute Open-Source-Verpackungssysteme umfassen dies heute, zumindest wenn Software aus offiziellen Repositories bezogen wird. Und selbst einmalige Projekte enthalten in der Regel Prüfsummen in Download-Bundles. In der Open Source-Welt wissen Sie nicht, dass der Code sicher ist, aber Sie wissen oft, dass Sie den Code erhalten, den Sie erhalten sollen. Mit Docker wissen Sie nicht einmal, dass der Container zwischen der Veröffentlichung und dem Herunterladen unverändert bleibt.

Zweitens geht es um das Paket selbst. Sind Sie sicher, dass die Software nichts Böses tut, z. B. Ihre Aktivitäten an ein Internetziel zu melden? Dies war früher eine verbreitete Angst vor Open Source-Software. Heutzutage stellen viele große Unternehmen keine technischen Implementierer in Frage, die Open Source-Software enthalten. Möglicherweise könnte Closed-Source-Software auf diese Weise schlechter sein. Aber für einen Docker-Container, insbesondere einen, der einen vollständigen Satz von Betriebssystem-Tools und -Bibliotheken enthält, ist die "Angriffsfläche" viel größer. Wenn Sie glauben, dass Sie einen schlechten Postfix-Build verwenden, holen Sie sich einfach den offiziellen Code und erstellen Sie ihn (und einige Paketmanager tun dies normalerweise). Wenn Sie glauben, einen schlechten Docker-Container zu haben, ist es oft ein Abenteuer, das Bild "von der Quelle" zu reproduzieren.

Können Sie den Docker-Containern von SECURITY vertrauen? Ich denke, die Antwort darauf muss fast immer NEIN sein!

In meinem Fall wundere ich mich über 'linuxserver / openvpn-as'. Wäre es nicht schön, das Ding einfach in einen meiner Docker-Schwärme zu stecken, es für meine privaten Netzwerke zu öffnen und den Remote-Benutzerzugriff auf diese Netzwerke verwalten zu lassen? Aber wie kann ich so etwas einem Container anvertrauen, den ich aus dem Internet bekomme und der keine Herkunft hat? Ohne das glaube ich nicht.

Wenn ich Herkunft hätte, müsste ich nur dem Schöpfer vertrauen, um

1. mit etwas zu beginnen, das ebenso vertrauenswürdig ist ( und so weiter und so fort),
2. hat nichts Bösartiges getan und
3. hat keine unsichere Wahl für einen Installations- oder Konfigurationsschritt getroffen.
ol>

Dies ist an und für sich eine ziemlich große Aufgabe. In diesem Fall muss ich linuxserver.io vertrauen. Nie von ihnen gehört. Aber wenn man sie betrachtet, scheint es ihre gesamte Aufgabe zu sein, Container zu erstellen. Also sind sie wahrscheinlich wirklich gut darin. Und dieser Container wurde angeblich über 500.000 Mal von DockerHub heruntergeladen. Klingt nach etwas ziemlich Sicherem.

Ich könnte mich also wahrscheinlich ziemlich gut fühlen, wenn ich sicher sein könnte, dass das Bild, das ich erhalte,

1. von linuxserver.io und erstellt wurde
2. ist in der Tat DAS Bild, das wirklich 500K-mal heruntergeladen wurde.

Nun, zuallererst ist (2) nicht wahr, oder? Ich glaube, das zählt alle Versionen des Containers. Vielleicht ist der Container seit Jahren sicher, aber jemand hat NUR eine Version mit einer ernsthaften Sicherheitslücke veröffentlicht. Und dann ist da noch (1). Das ist der wahre Stinker. Wie vielen anderen Mechanismen muss ich vertrauen (DockerHub, DockerHubs Hoster, Internetinfrastruktur, ...), um sicherzustellen, dass der ursprüngliche Quellcode für den Container, den linuxserver.io als Quelle für den Container betrachtet, den vollständig definiert Container, den ich tatsächlich benutze. Ich kann das auf keinen Fall wissen. Und wirklich, ich müsste das nicht nur über diesen Container wissen, sondern über alle Untercontainer, die zum Erstellen verwendet wurden. Daher kann ich diesen Container unmöglich verwenden.

Dies ist ein Extremfall, aber wahrscheinlich nicht für Container mit Netzwerksicherheit. Ich gehe davon aus, dass viele der 500.000 Konsumenten, die dieses Image tatsächlich verwendet haben, dies ohne Verschulden von linuxserver.io rücksichtslos getan haben.

Docker benötigt einen vollständigen Mechanismus zur Herkunft von Containern. Selbst dann gibt es hier viel Vertrauen. Vielleicht zu groß. Möglicherweise ist Sicherheitssoftware einfach nicht containerisierbar.

Sie können durch eine schnelle Untersuchung Vertrauen in die Quelle aufbauen. Ein grundlegenderes Problem ist jedoch die relative Unreife des gesamten Sicherheitsprofils, die sich aus der Notwendigkeit ergibt, Root-Zugriff zum Ausführen Ihres Containers zu verwenden.

Seitdem Sie schlagen vor, dass wir uns auf beliebte Lösungen konzentrieren. Nehmen wir an, wir verwenden ein kontrolliertes Git-basiertes Repository wie Docker Hub, um ein beliebtes vom Hersteller bereitgestelltes Produkt herunterzufahren. Die Git-Mechanismen bieten eine gute Vertrauensschicht. Wenn Sie dem genannten Anbieter vertrauen, können Sie dessen Docker-Produkt vertrauen. Wenn Sie sich erinnern, dass GitHub vor einigen Jahren kompromittiert wurde, der Quellcode jedoch aufgrund des Integritätssignaturmechanismus und der Veröffentlichungssteuerelemente von Git in Ordnung war. Diese Funktionen schützen auch von Docker veröffentlichte Dateien, wenn Sie beliebte Herstellerprodukte verwenden.

Die Docker-Datei, die Ihren Container erstellt, kann TAR-Dateien usw. erreichen und herunterladen, die nicht in vertrauenswürdigen Git-Repositorys gehostet werden. Eine einfache Überprüfung dieser Textdatei, der Docker-Datei, kann Vertrauen in diesen Bereich schaffen.

Die allgemeinen Sicherheitsmechanismen sind sehr jung. Berücksichtigen Sie daher zusätzlich zu den Fragen der Quellcodeverwaltung auch ihre Schwachstellen. Aus der Sicherheitsdokumentation geht hervor:

Bei der Überprüfung der Docker-Sicherheit sind drei Hauptbereiche zu berücksichtigen:

• die intrinsische Sicherheit des Kernels und seine Unterstützung für Namespaces und cgroups
• die Angriffsfläche des Docker-Daemons selbst
• Lücken im Containerkonfigurationsprofil, entweder standardmäßig oder wenn sie von Benutzern angepasst werden
• die "härtenden" Sicherheitsfunktionen von Der Kernel und wie sie mit Containern interagieren

Ich denke, die Tatsache, dass ihre Titelseite zur Sicherheit besagt, dass es drei Hauptbereiche gibt und dann vier auflistet, ist ein weiterer Hinweis darauf, dass sich die Dinge darin ändern Raum. Es scheint eine fantastische Lösung zu sein, erfordert jedoch möglicherweise in naher Zukunft eine intelligente Härtung mit vom Benutzer bereitgestellten Perimetern und Richtlinien.

Insbesondere mit Docker können Sie meiner Erfahrung nach darauf vertrauen, dass die überwiegende Mehrheit der Inhalte in der Open Source-Community (wie z. B. Inhalte auf Github) nicht absichtlich bösartig ist. Sie können die Docker-Datei lesen und überprüfen, ob sie Code aus offiziellen Repos abruft, falls vorhanden (im Gegensatz zur Verwendung der Gabel einer zufälligen Person). Wenn es sich um Code handelt, der von einem seltsamen Ort stammt, können Sie sich natürlich jederzeit ansehen, was sich vom offiziellen Repo in dieser speziellen Gabel unterscheidet. Hier gelangen Sie in schädliche Software, die nicht absichtlich bösartig ist. Es ist nur Mistcode oder schreckliche Konfiguration oder gleichwertig. Nach meiner Erfahrung mit Docker sollte Code, der inoffizielle Gabeln verwendet, vermieden werden, es sei denn, die Gabel bietet eine bestimmte Funktion, nach der Sie suchen. Das offizielle Repo wird fast allgegenwärtig aktualisiert als die Gabel. Außerdem verwendet Docker sogenannte "vertrauenswürdige Builds", damit Sie wissen, dass Sie das bekommen, was es verspricht. Schließlich hatte Docker selbst Schwachstellen. Es hört sich so an, als hätten Sie die richtige Einstellung, um sich ein Bauchgefühl zu geben, wenn etwas nicht stimmt.

In weniger Worten, im Allgemeinen, wenn Ihre Docker-Ressourcen FROM aus einem offiziellen Build ziehen und from offizielle Repos, dies ist ungefähr so ​​sicher, wie Sie mit Software bekommen können. Docker selbst hatte einige Schwachstellen, aber solange Sie über das Patchen Ihrer Infrastruktur auf dem Laufenden bleiben, ist alles in Ordnung.

Nehmen Sie die Standardhaltung an, nichts zu vertrauen, das Sie von außen in Ihre Umgebung bringen möchten.

Wenn Sie es wirklich verwenden möchten, minimieren Sie das Risiko so weit wie möglich, indem Sie es binden, analysieren und sicherstellen, dass es keinen Schaden anrichtet.

Geben Sie ihm so wenig Zugriff wie möglich auf Ihre Umgebung, damit er das tun kann, was Sie benötigen.

Überprüfen Sie ihn. Aktualisieren Sie es und stellen Sie sicher, dass die Updates kein neues Risiko darstellen.