Login
Newsletter
Werbung

Thema: Geldsorgen bei Docker?

39 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ruediger am Mi, 2. Oktober 2019 um 19:10 #

Ich habe noch nie was von Docker Swarm gehört. Gibt es das wirklich?

  • 0
    Von inta am Mi, 2. Oktober 2019 um 23:08 #

    Das gibt es und es funktioniert. Swarm ist einfacher als Kubernetes, was ihm eigentlich einen Vorteil verschaffen sollte (aber offensichtlich nicht tut).

0
Von Andy_m4 am Mi, 2. Oktober 2019 um 21:39 #

Die Zukunft von Docker erscheint also im Moment eher schwierig.
Man gut, das ich nicht auf den Docker-Zug aufgesprungen bin.

  • 0
    Von Sergey am Mi, 2. Oktober 2019 um 21:59 #

    Das rot-behütete Unternehmen aus den Staaten reibt sich gerade die Hände.

    1
    Von Falk am Do, 3. Oktober 2019 um 00:44 #

    Ist doch freie Software. Das verschwindet nicht wieder. Dafür ist es viel zu praktisch. Z.B. setzte ich doch heute keine Entwicklerdatenbank mehr selbst auf. Die nehme ich vorgefertigt und wenn es eine andere sein soll, dann ist das in kürzester Zeit getauscht und auch wieder zurück. Aber auch, wenn ich Software verteilen muss, dann kann ich es mir z.B. sparen, die Java-Version mit anderer Software abzustimmen (OK, das könnte man auch anders erreichen). Auch Sicherheitslücken sind schwerer auszunutzen - ein Java, das nur in einem Container läuft, hätte nie einen Browser kompromittieren können (OK, es gibt keine Applets mehr).

    Edit:
    Ich kann auch auf einem Rechner gleichartige Testumgebungen laufen lassen, ohne dass die sich stören. Intern arbeitet alles mit den Standardports und nach außen natürlich unterschiedliche Ports. Und das alles ohne dass man auf dem Hostsystem außer Docker weitere Software installiert.

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Okt 2019 um 00:49.
    • 0
      Von Andy_m4 am Do, 3. Oktober 2019 um 11:38 #

      Z.B. setzte ich doch heute keine Entwicklerdatenbank mehr selbst auf. Die nehme ich vorgefertigt und wenn es eine andere sein soll, dann ist das in kürzester Zeit getauscht und auch wieder zurück.
      Was ist jetzt konkret am Datenbanken aufsetzen so schwer, das man dafür irgendwas z.B. von Dockerhub nehmen muss wo man noch nicht mal weiß, ob das alles wirklich koscher ist?

      Aber auch, wenn ich Software verteilen muss, dann kann ich es mir z.B. sparen, die Java-Version mit anderer Software abzustimmen (OK, das könnte man auch anders erreichen)
      Eben. Kann man auch anders erreichen. Bei Docker hab ich das Problem dann auch noch jeden Container einzeln warten zu müssen. Ja. Auch dafür gibts Werkzeuge. Aber letztlich stapelst Du unnötig Komplexität drauf nur um an einer Stelle nen vermeintlichen Vorteil zu haben.

      uch Sicherheitslücken sind schwerer auszunutzen
      Jaein. Docker ist kein Sicherheitsfeature. Es war ursprünglich auch gar nicht als ausbruchssicherer Container gedacht. Man hat es inzwischen nachgrüstet. Ist aber eben nicht secure-by-design.

      Ich hab auch nichts dagegen Container einzusetzen. Ich habe aber den Eindruck, das es heute vielfach gemacht wird, weils IN ist. Docker mehr als Verkaufsargument als wirklich immer technische Notwendigkeit.

      Und Container sind ja auch nun keine Neuigkeit. Ihr solltet euch mal fragen, wenn das angeblich alles so praktisch ist, warum habt ihr es dann nicht schon vor 10 Jahren gemacht?

      • 0
        Von Falk am Do, 3. Oktober 2019 um 13:06 #

        Was ist jetzt konkret am Datenbanken aufsetzen so schwer, das man dafür irgendwas z.B. von Dockerhub nehmen muss wo man noch nicht mal weiß, ob das alles wirklich koscher ist?
        Dass man sie für jedes Projekt auswechseln kann und auch wieder zurück. Auch verschiedene Stände. Dass man das, was man entwickelt hat, unter Umständen auch sehr einfach verteilen kann. Vorgefertigt und schon komplett aufeinander angestimmt.

        Und wenn man die offiziellen MariaDB-Container nimmt (oder eines großen Projektes wie z.B. Bitnami) warum soll das nicht koscher sein? Auch ansonsten kannst du dir ja die Dockerfiles ansehen und es selber bauen. Das Problem hast du auch bei jeder anderen Distribution und bei jedem anderen Open Source Projekt.

        Jaein. Docker ist kein Sicherheitsfeature. Es war ursprünglich auch gar nicht als ausbruchssicherer Container gedacht. Man hat es inzwischen nachgrüstet. Ist aber eben nicht secure-by-design.
        Software, die auf deinem Hostsystem nicht ansprechbar ist, ist auch nicht für einen Exploit zu benutzen. Wenn Java auf deinem Hostsystem nicht direkt läuft, dann kann man keine Java-Programme dort starten, um etwas zu verändern.

        Aber natürlich - für das Öffnen an sich ändert sich praktisch nichts. Hier sind die Sicherheitslücken der einzelnen von außen erreichbaren Programme entscheidend. Außer wie geschrieben, dass ein Dockercontainer normalerweise ein minimales System darstellt und man mit der Einbruchslücke kaum auf Hilfe durch Kombination mit anderer Software hoffen kann. Also das, was auch eine ChRoot-Umgebung attraktiv macht.

        Wenn du allerdings nur Standardsoftware hostet - keine Ahnung - dann gehts wohl auch ganz toll ohne. Ich bin eh kein Admin, habe mit Clustern bisher nichts am Hut (auch ein Gebiet, wo Docker-Container zusammen Kubernetes oder Swarm sehr schön je nach Last den Cluster verkleinern und vergrößern können -> AWS). Aber zur Entwicklung ist das schon sehr schön.

        • 0
          Von 1ras am Do, 3. Oktober 2019 um 15:02 #

          Dass man sie für jedes Projekt auswechseln kann und auch wieder zurück. Auch verschiedene Stände.

          Während der Entwicklungsphase sicher super, im Produktivbetrieb dagegen weniger, da dort andere Anforderungen gelten. Möglichst viele Abstraktionsschichten unter und über die Datenbank zu legen um sie bei ihrer effizienten Arbeit zu behindern, gehört da eher nicht dazu.

          Dass man das, was man entwickelt hat, unter Umständen auch sehr einfach verteilen kann. Vorgefertigt und schon komplett aufeinander angestimmt.

          Ein Projekt steht und fällt mit seiner Dokumentation. Wenn diese so schlecht ist, dass das System in akzeptabler Zeit nicht neu installiert werden kann, lässt man am Besten die Finger davon.

          Dieser Ansatz, wir schieben einfach fertige Container zu unseren Kunden, dann müssen wir uns mit der Installation und Dokumentation nicht mehr beschäftigen führt in absehbarer Zeit nur dazu, dass dann auch niemand mehr in der Lage sein wird eine Installation durchzuführen.

          Und wenn man die offiziellen MariaDB-Container nimmt (oder eines großen Projektes wie z.B. Bitnami) warum soll das nicht koscher sein? Auch ansonsten kannst du dir ja die Dockerfiles ansehen und es selber bauen.

          Nur kannst du es dann auch gleich für das Zielsystem bauen.

          Das Problem hast du auch bei jeder anderen Distribution und bei jedem anderen Open Source Projekt.

          Das Problem besteht nun aber doppelt, sowohl für das Hostsystem wie auch für den Container. Doppelte Datenhaltung eben. Also genau das was du in einer Datenbank nicht haben möchtest, nämlich Daten an unterschiedlichen Stellen doppelt vorzuhalten, machst du jetzt auf Hostsystem- und Containerebene.

          Software, die auf deinem Hostsystem nicht ansprechbar ist, ist auch nicht für einen Exploit zu benutzen. Wenn Java auf deinem Hostsystem nicht direkt läuft, dann kann man keine Java-Programme dort starten, um etwas zu verändern.

          Durch Erhöhung der Komplexität verringerst du in der Regel nicht den Angriffsvektor. Lohnende Angriffsziele sind alle Systeme welche Zugriff auf die Daten haben und das sind dann eben die Container.

          Das schwächste System wird den Angriff nicht standhalten. Und da du plötzlich für die *gesamte* Software welche du im Container deines Produktes auslieferst verantwortlich bist, hast du plötzlich Arbeit am Hals welche dir sonst die Distributionen abgenommen haben. Und gibt es eine Sicherheitslücke in einer Bibliothek welche du einsetzt, bist du es der in deinem Produkt genau so schnell ein Update bereitstellen muss, wie die Distribution des Hostsystems, ansonsten bist es nämlich du, der den Angriffsvektor erhöht und das schwächste System liefert. Man muss kein Hellseher sein um zu erkennen, dass es in der Praxis die Container sein werden wo Sicherheitslücken klaffen, welche auf dem Hostsystem schon lange behoben wurden.

          Aber natürlich - für das Öffnen an sich ändert sich praktisch nichts. Hier sind die Sicherheitslücken der einzelnen von außen erreichbaren Programme entscheidend. Außer wie geschrieben, dass ein Dockercontainer normalerweise ein minimales System darstellt und man mit der Einbruchslücke kaum auf Hilfe durch Kombination mit anderer Software hoffen kann. Also das, was auch eine ChRoot-Umgebung attraktiv macht.

          Dein Container ist demnach ein Workaround für ein falsch gewähltes oder aufgesetztes Hostsystem. Denn bei einem geeigneten Hostsystem stellt sich diese Problematik nicht.

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Okt 2019 um 15:03.
          • 0
            Von Falk am Do, 3. Oktober 2019 um 16:00 #

            Es gibt immer mehrere Wege zum Ziel. Ein vernünftig klassisch gemangtes System hat seinen Wert, seine Berechtigung und ohne Grund sollte man keine Software einsetzten. Das gilt auch für Docker.

            Während der Entwicklungsphase sicher super, im Produktivbetrieb dagegen weniger, da dort andere Anforderungen gelten. Möglichst viele Abstraktionsschichten unter und über die Datenbank zu legen um sie bei ihrer effizienten Arbeit zu behindern, gehört da eher nicht dazu.
            Ja, das ist ein Feature für die Entwicklung. Vor allem, wenn man für verschiedene Projekte und Branches entwickelt.

            Ein Projekt steht und fällt mit seiner Dokumentation. Wenn diese so schlecht ist, dass das System in akzeptabler Zeit nicht neu installiert werden kann, lässt man am Besten die Finger davon.

            Dieser Ansatz, wir schieben einfach fertige Container zu unseren Kunden, dann müssen wir uns mit der Installation und Dokumentation nicht mehr beschäftigen führt in absehbarer Zeit nur dazu, dass dann auch niemand mehr in der Lage sein wird eine Installation durchzuführen.

            Mich interessiert vor allem die Entwicklersicht. Auch für Testssysteme gilt, dass man die erstmal komplett einrichten muss. Warum soll ich da nichts nehmen, was schon alle Dependencies drin hat und dann auch einfach wieder raus geht (ja ich weiß - das kann man auch mit fast jeder modernen Paketverwaltung). Übrigens auch ohne, dass sich da was beißt. Man muss sich z.B. nicht zwischen PHP5 und PHP7 entscheiden. Es geht einfach beides. Wohl gemerkt - in der Entwicklung gibt es dauernd solche Fälle.

            Und auch produktiv: Cloudsysteme, die hoch und runterskaliert werden sollen, bei denen kann man Docker sicher gut benutzen.

            Das schwächste System wird den Angriff nicht standhalten. Und da du plötzlich für die *gesamte* Software welche du im Container deines Produktes auslieferst verantwortlich bist, hast du plötzlich Arbeit am Hals welche dir sonst die Distributionen abgenommen haben.
            Für Container gibt es ganz genau so Distributionen. Im Zweifel sind das die gleichen Linux-Distributionen, die halt nur minimalistisch im Container laufen. Da ist häufig nicht mal ein curl, ping, apt/dnf/rpm oder sudo dabei (Edit: häufig aber auch doch, aber zumindest nichts, was über die minimalen Standardtools hinausgeht). Wenn das keine Verringerung der Angriffsfläche darstellt, dann weiß ichs auch nicht.

            Dein Container ist demnach ein Workaround für ein falsch gewähltes oder aufgesetztes Hostsystem. Denn bei einem geeigneten Hostsystem stellt sich diese Problematik nicht.

            Nein. Die Dienste sind einfach voneinander isoliert.

            Ein akademisches Beispiel: Gitlab, Nexus, Apache/Nginx und Jenkins wissen nur voneinander die Ports, die durchgeroutet werden. Ansonsten wird man aus einem Reverse Proxy kein Maven oder Java aufrufen können. Selbst durch einen Bug in Nginx nicht. Denn diese Programme sind nur beim Jenkins verfügbar.

            Trotzdem läuft alles auf einem einzigen Host.

            Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Okt 2019 um 16:26.
            • 0
              Von 1ras am Do, 3. Oktober 2019 um 21:04 #

              Und auch produktiv: Cloudsysteme, die hoch und runterskaliert werden sollen, bei denen kann man Docker sicher gut benutzen.

              Cloudsysteme laufe doch in der Regel nicht auf der Bare-Metall-Hardware sondern in virtuellen Maschinen, welche diese Features seit längerem mitbringen.

              Für Container gibt es ganz genau so Distributionen. Im Zweifel sind das die gleichen Linux-Distributionen, die halt nur minimalistisch im Container laufen. Da ist häufig nicht mal ein curl, ping, apt/dnf/rpm oder sudo dabei (Edit: häufig aber auch doch, aber zumindest nichts, was über die minimalen Standardtools hinausgeht). Wenn das keine Verringerung der Angriffsfläche darstellt, dann weiß ichs auch nicht.

              Du erhöhst erstmal die Komplexität indem du zahlreiche Dinge mehrfach vorhältst und ungeklärt ist, wer sich überhaupt um die Aktualität der einzelnen, völlig unterschiedlichen Systeme kümmert. Und in der Praxis werden dort dann auch wieder zahlreiche Tools der Entwickler und fürs Troubleshooting auch auf den an Endkunden ausgelieferten Systemen vorhanden sein. Ob da überhaupt noch etwas vom Versprechen der geringeren Angriffsfläche übrig bleibt, kann allerhöchstens im Einzelfall geklärt werden.

              Nein. Die Dienste sind einfach voneinander isoliert.

              Ein akademisches Beispiel: Gitlab, Nexus, Apache/Nginx und Jenkins wissen nur voneinander die Ports, die durchgeroutet werden. Ansonsten wird man aus einem Reverse Proxy kein Maven oder Java aufrufen können. Selbst durch einen Bug in Nginx nicht. Denn diese Programme sind nur beim Jenkins verfügbar.

              Trotzdem läuft alles auf einem einzigen Host.

              Für diese Anwendung brauchst du nur keine Container. Es gibt unter Linux zahlreiche Möglichkeiten einzelne Dienste voneinander abzuschotten, ohne gleichzeitig den Angriffsvektor durch das mehrfache Vorhandensein der selben Bibliotheken und Standardtools zu erhöhen.

              Aus Entwicklersicht in einer Entwicklerumgebung alles wunderbar, kein Thema. Ich habe nur ein Problem mit der Argumentation "alles wird viel sicherer" mitzugehen, wenn dafür die Komplexität erhöht, identische Sicherheitslücken plötzlich zigfach auf dem System vorhanden sind und die Wartungssituation sowie dessen Mehraufwand ungeklärt sind.

              • 0
                Von Falk am Do, 3. Oktober 2019 um 22:59 #

                Sicherlich. Ich würde ohne weitere Überlegungen auch kein System mit "Gitlab, Nexus, Apache/Nginx und Jenkins" im Docker aufsetzen, das nach außen sichtbar ist. Das braucht man wirklich nicht beim Kunden. Wenn es auf einen kleineren Benutzerkreis beschränkt ist und z.B. durch ein VPN geschützt ist dann allerdings ja. Geht halt einfach schnell und ist flexibel.

                Und es ist natürlich eine Option, wenn es wirklich groß wird und man wirklich anfängt, dynamisch Knoten zu verschieben. Aber dann erstellt man wohl auch die Dockerfiles selbst.

                Container sind einfach minimale VMs. Ansonsten klar - da hast du recht und ich betreibe warte keine Server. Ich schreibe nur die Software dafür.

                • 0
                  Von Falk am Fr, 4. Oktober 2019 um 11:54 #

                  Kleine Korrektur:
                  Unter Windows ist eine Virtualisierung notwendig. Hat man kein Windows 10 Pro oder höher (mit Hyper-V), benötigt man unter Windows eine Virtualisierungslösung wie z.B. Virtualbox.

                  Unter Linux scheint wohl nur Namespaces und Cgroup verwendet zu werden. Wie das Docker genau macht, müsste ich mir also selbst noch mal ansehen. Allerdings bleibt es dabei, dass Container eine vom Hostsystem unabhängige komplette aber meist sehr kleine Linuxinstallation mitbringen und nur über genau definierte Schnittstellen mit der Außenwelt interagieren dürfen.

          0
          Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:06 #

          Container sind kein ausreichendes Sicherheitsfeature - PUNKT

          • 0
            Von Falk am Do, 3. Oktober 2019 um 19:14 #

            Hat das wer behauptet - FRAGEZEICHEN

            Was ist das überhaupt für eine Aussage. Ein Login ist auch kein ausreichendes Sicherheitsfeature. Und du schon garnicht.

            PS:
            Von dir brauch ich nicht wirklich eine Antwort.

            • 0
              Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:36 #

              Nun, viele Kommentare hier und allgemein gehen in die Richtung

              Das was docker isolationstechnisch leistet kann ein systemd unit genauso gut und vernünftige Software braucht nicht genau Version x von library y kombiniert von z

              • 0
                Von hahaha am Sa, 5. Oktober 2019 um 09:44 #

                Ein systemd unit? ????????????

                • 0
                  Von Lennartwarehouse am Sa, 5. Oktober 2019 um 09:49 #

                  Ja, eine systemd unit entspricht in etwas 10 Kilo systemkritsche Kernelbugs. Der Umrechnungskurs ist schon lange stabil. Ist ja kein Bitcoin.

                  • 0
                    Von Verfluchtnochmal_5987108 am Sa, 5. Oktober 2019 um 17:21 #

                    Faszinierend wie wenig Ahnung man haben kann und wie laut man das raus schreien muss! Die namespaces machen weder docker noch systemd selbst, das sind lediglich Schnittstellen zum Kernel

                    Sorry, aber wer 2019 noch initscripts benutzt hat sich in die falsche Branche verlaufen

                  1
                  Von Verfluchtnochmal_5987108 am Sa, 5. Oktober 2019 um 17:32 #

                  Noch nie gesehen?

                  ProtectSystem, ProtectHome, ProtectControlGroups, ProtectKernelModules, ReadOnlyPaths, ReadWritePath, InaccessiblePaths, LockPersonality, NoNewPrivileges, PrivateDevices, PrivateTmp, RestrictNamespaces, SystemCallFilter, CapabilityBoundingSet, AmbientCapabilities

                  Vor allem in Kombination mit PermissionsStartOnly kannst du damit in ExecStartPre und ExecStopPost mit vollem root Rechten agieren und den eigentlichen Dienst trotzdem maximal einschränken

                  Einfach mal RTFM und in 2019 ankommen bevor es vorbei ist

              0
              Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:42 #

              Und ja auch du hast in deinem ersten Post von "Sicherheitslücken schwerer auszunutzen" gesprochen während das Gegenteil wahr ist, die scheiss container sind üblicherweise mies gepflegt was enthaltene libraries betrifft und inflationär eingesetzt ist das ein horror

              Aber nachdem du wie du sagtest ja eh kein admin bist wozu erzähle ich das einem "devops" der ohne container keine testumgebungen aufzusetzen im stande ist

              • 0
                Von Konstantin Bläsi am Do, 3. Oktober 2019 um 22:26 #

                Pflege von containern ist viel einfacher. Dass man sie - wie alles andere - auch pflegen muss wer hätte das gedacht!

                0
                Von Falk am Do, 3. Oktober 2019 um 22:33 #

                Du musst schon die Container benutzen, die passen. Also für einen Server nicht die Entwicklercontainer nehmen. Und wenn du noch höhere Ansprüche hast, dir z.B. ein Alpine Linux nicht genügt, ja mein Gott - dann beginnst du halt "FROM scratch", machst weiter mit "ADD Verfluchtnochmal_5987108.tgz".

                Trotzdem bleibt das getestete Software in einer minimalen Umgebung - normalerweise direkt vom Open Source Projekt konfiguriert und paketiert. Ohne Seiteneffekte, die deine Konfiguration zerlegen könnten. Mit nur den absolut notwendigen Schnittstellen nach draußen. Und das System kannst du auf deiner Hardware dann auch gleich mehrfach und trotzdem getrennt laufen lassen.

                Weil du aber alles besser weißt und neben deinem abstoßenden Namen hier auch noch alle möglichen Leute durchbeleidigst (heute bin ich es wohl), werde ich ab jetzt nicht mehr auf auf deine scheinbar tiefsinnigen Posts antworten.

                Ich bleibe dabei "Sicherheitslücken sind schwerer auszunutzen", es sei denn, du compilierst und paketierst alles selbst - und zwar anders als die Distributionen (damit Standard-Exploits möglichst nicht mehr durchlaufen). Aber das kannst du auch mit Containern machen. Siehe oben. Du splittest dein System halt auf, wenn auf einer Maschine unterschiedliche Dienste laufen.

                Und gleich nochmal - ich habe nie behauptet, dass das der einzige Weg ist, Dienste zu isolieren. Und ich habe nie behauptet, dass das immer sinnvoll ist. Es ist aber praktisch mit den in sich getesteten Softwareeinheiten, die nun problemlos in Größe und Funktion kombiniert werden können und die Container werden auch nicht mehr verschwinden.

                • 0
                  Von Verfluchtnochmal_5987108 am Fr, 4. Oktober 2019 um 04:42 #

                  Zur Isolation verwendet man VM's, die werden auch nicht verschwinden und ja ich baue software für Dienste die im Netz hängen selbst so optimiert und gehärtet wie nur möglich plus alles was systemd an Sicherheitsoptionen hergibt und schreiben run wir die darauf laufende Software auch seit ich denken kann selbst, heute nennt man das wohl DevSecOps

                  • 0
                    Von Anonymous am Fr, 4. Oktober 2019 um 11:52 #

                    wirres Zeug ohne Punkt und Komma, geschrieben um 4:42 Uhr

                    Auf'm AFN gab's in meiner Jugend einen (nichtkommerziellen) Werbespot, in dem eine Horde Betrunkener ein Lied grölte, das man kaum erkennen konnte.

                    Aus dem OFF kam dann eine Stimme: "They think they can sing. They also think they can drive. Don't drink and drive!"

0
Von hoppschwiz am Mi, 2. Oktober 2019 um 22:39 #

was bedeutet das? ich lese das oft in deutschen Medien.
Ich kenne noch unter hohem Druck, mit Nachdruck odfer auf Hochtouren.
Aber mit Hochdruck? HÄ?

1
Von yahya am Mi, 2. Oktober 2019 um 23:41 #

Ich finde Docker ziemlich genial, es wäre jammerschade, wenn das nicht mehr weiterginge!!

  • 0
    Von Alzheimer am Do, 3. Oktober 2019 um 14:17 #

    Genial hin oder her. Wozu braucht man Docker und warum tut es nicht einfach auch eine herkömmliche CHROOT-Umgebung?

    • 0
      Von Falk am Do, 3. Oktober 2019 um 14:50 #

      ChRoot ist Distributions- und Betriebssystemabhängig. Docker nicht. Einmal ein Dockerimage erstellt und es läuft überall. Es ist normalerweise auch alles konfiguriert. Es funktioniert einfach. Man kann Dinge sehr gut auch in großen Umgebungen verteilen und umverteilen (mache ich nicht -> Kubernetes oder Swarm wären hier sinnvoll).

      Man kann auch genau beschränken, wie der Container kommunizieren darf. Wie der Container erreicht werden darf sowieso (normalerweise nur ein Port), aber auch was er nach außen darf. Wenn da etwas untergeschobenes auf einem anderen Port lauschen möchte - es wird nicht funktionieren.

      Aber selbstverständlich kann Docker auch eine neue Sicherheitslücke öffnen - es ist schließlich eine Software wie jede andere auch.

      0
      Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:33 #

      Ich hätte gerne einen Euro für jedes chroot setup dem elementare Dinge wie /dev/urandom & Friends fehlen

      Mit einem normalen systemd unit und all den namespace-optionen erreiche ich die gleiche Sicherheit sauberer weil sich bei Dingen wie PrivateDevices=yes jemand was gedacht hat uid vor allem kann ich viel mehr limitierten

      cgroups/namespaces etc mit systemd sind container ohne die Komplexität mitzuschleppen

      Für echte Isolierung kommst du an einer VM nicht vorbei

      0
      Von Konstantin Bläsi am Do, 3. Oktober 2019 um 21:39 #

      Ganz einfach, weil chroot != docker. Lesen hilft.

    0
    Von Konstantin Bläsi am Do, 3. Oktober 2019 um 21:49 #

    Das Überleben von containern hängt doch nicht von der Firma docker ab! Docker hat es bekannt und bequem gemacht (mit allen Vor- und Nachteilen) nicht mehr und nicht weniger.

0
Von kamome umidori am Fr, 4. Oktober 2019 um 11:08 #

> Dies wurde auch von der Anforderung getrieben, Container ohne Root-Berechtigungen betreiben zu können. Docker ignorierte dies zu lange und führte es erst in Version 19.03 ein, und dort auch nur als experimentelle Funktionalität.

Das hatte ich als _die_ Schwachstelle von Docker empfunden, meines Wissens wurde das aber „schon“ mit Version 1.10 durch User Namespaces möglich:

> Docker supports user namespaces after 1.10, but Docker does not set these by default.
(https://runnable.com/docker/securing-your-docker-system)

Wenn es mir auch unverständlich ist, dass das jemals ohne ausgeliefert wurde und selbst danach nicht überall eingesetzt wurde. Und dann meist noch als root innerhalb der Container … damit oft sogar unsicherer als chroot, weil man dort vielleicht noch versucht hätte, einen Prozess nicht als root laufen zu lassen, vielen Nutzern/Entwicklern aber wohl gar nicht bewusst war, dass es in Containern recht üblich war, alles als root laufen zu lassen.

  • 0
    Von Verfluchtnochmal_5987108 am Sa, 5. Oktober 2019 um 05:43 #

    Und genau diese Leute die zu blöde sind zucschauen mit welchen Rechten was läuft erzählen dann wie sicher nicht alles sei was sie so erbrechen weil sie ja container benutzen die aber niemals ein security Feature waren

0
Von Linuxadmin_Kernel418 am Mo, 7. Oktober 2019 um 14:52 #

Docker hier und Docker da.
Und stetig kommen SOFORT die Docker Fanboys aus dem letzten Loch gekrochen und versuchen Ihren unqualifizierten Stuss gestandenen Admins zu erklären.
Nicht das Docker per se schlecht ist...doch auch hier in den Kommentaren sehe ich, wie "Entwickler" glauben nun Server aufzusetzen.

Ich hab selbst damit zu tun...und noch nie, hat jemals ein Entwickler (weder bei "uns" noch bei Kunden) die Basics verstanden. Stattdessen werden immer wieder die gleichen Dinge nachgeplappert.
Achtet mal drauf, die Fanboys "ALLES" in Docker packen wollen...(was quatsch ist).

Container gehören in Profi Hände, gerne (!) mit Support der Entwickler...aber niemals nur in Entwickler Hände und niemals "einfach mal so".
Spielen könnt ihr zu hause !

  • 0
    Von Verfluchtnochmal_5987108 am Di, 8. Oktober 2019 um 02:03 #

    Dass niemals ein Entwickler die basics verstanden hat ist so auch schmarren, ich komme ursprünglich aus der Softwareentwicklung und habe vor 11 Jahren auch die Administration komplett übernommen

    Schlicht und ergreifend weil reine Admins noch viel weniger Basics verstehen, unterm Strich ist keiner ernst zu nehmen der nicht beides beherrscht

    Warum?

    weil ein Entwickler der keine Ahnung hat was unter der Haube funktioniert genauso wenig zu brauchen ist wie ein admin in seinem Elfenbeinturm der die Anforderungen der Anwendung on top zwar auf Zuruf erfüllen kann aber das warum nur erahnt

    Wenn du beides kontrollierst und beherrscht kannst du wesentlich weiter bei hardening und Optimierungen auf beiden Seiten gehen, sowohl was security als auch Performance betrifft

    • 0
      Von Linuxadmin_Kernel418 am Di, 8. Oktober 2019 um 16:49 #

      Ich kenne keine Entwickler die außer ihren Code und Git pushing, etwas anderes können ! Bereits bei einem ER Diagramm ist schon Schluss...

      "ich komme ursprünglich aus der Softwareentwicklung und habe vor 11 Jahren auch die Administration komplett übernommen"
      Und ? Erwartest Du jetzt das ein Admin den kompletten Code einer 10.000.000 LOC Anwendung kennt ?

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung