Wie stellt man eigentlich Patchmanagement in Docker Containern / Kubernetes Clustern sicher? Erstmal muss ich ja sicherstellen, dass ich immer das aktuellste Image nutze. Aber das reicht ja nicht. Ich weiß schließlich nicht, ob im Image auch die aktuellen Sicherheitsupdates des Betriebssystems installiert sind. Wie auditiere ich also den Patchstand und wie korrigiere ich ihn bei Bedarf? Ein anderes Problem ist immer auf latest zu setzen. Ich merke dann gar nichts von Breaking Changes und bei irgendeinem (automatischen) Update fliegt mir alles auseinander. Dann kommt noch dazu, dass bestimmte Images zum Beispiel eine ältere Datenbankserver Version brauchen. Ich muss also den Tag fix auf die Version setzen, erhalte dann aber für den Tag keine Sicherheitsupdates mehr. So ist das doch alles Murks! Nehme ich dagegen ein nacktes Debian oder CentOS/Rocky/RHEL, dann kümmert sich jemand für mich darum, dass ich Updates recht sorglos automatisch machen kann. Breaking Changes werden zurückgehalten und Security Fixes nachgeliefert. Automatische Updates lassen sich nachts einfach installieren. Wie kann ich dieses Verhalten auch in Docker Images erreichen? Muss ich alle meine Images dann selber bauen?
Laurenz schrieb: > Nehme ich dagegen ein nacktes Debian oder CentOS/Rocky/RHEL, dann > kümmert sich jemand für mich darum, dass ich Updates recht sorglos > automatisch machen kann. Richtig erkannt. Und wenn du deine eigene Applikation docketisieren willst, dann bist dieser Jemand du! Wer sonst soll wissen, was deine Applikation braucht? Es gibt zwar ein paar Möglichkeiten den aktuellen Minor von Abhängigkeiten zu referenzieren - aber normalerweise sollte deine App ja nicht allzuviel brauchen und da musst du halt schauen, dass das aktuell ist und zusammenpasst.
Laurenz schrieb: > Ich muss also den Tag fix auf die > Version setzen, erhalte dann aber für den Tag keine Sicherheitsupdates > mehr. So ist das doch alles Murks! "gute" Images bieten da Tags an, die auch auf kompatible Versionen mit Sicherheits-Updates passen. z.B. mit "postgres:12" kriegst du kein ungefragtes Update auf 13 oder 14, sondern die aktuelle 12.12er Version. Im Unterschied zu "postgres:12.12" kriegst du aber ein Update, sollte eine 12.13er-Version erscheinen. Trotzdem: Laurenz schrieb: > Muss ich alle meine Images dann selber bauen? Ja. Mehr oder weniger. Kannst auch irgendwo eine Grenze ziehen, welchen Projekten du zutraust, zeitnah Sicherheitsupdates zu integrieren, und ab welcher Ebene du selber baust. Z.B. den Debian-Basis-Images vertrauen, darauf aufbauende Dockerfiles selber bauen lassen.
Jan H. schrieb: > Laurenz schrieb: > >> Nehme ich dagegen ein nacktes Debian oder CentOS/Rocky/RHEL, dann >> kümmert sich jemand für mich darum, dass ich Updates recht sorglos >> automatisch machen kann. > > Richtig erkannt. Und wenn du deine eigene Applikation docketisieren > willst, dann bist dieser Jemand du! Wer sonst soll wissen, was deine > Applikation braucht? > Es gibt zwar ein paar Möglichkeiten den aktuellen Minor von > Abhängigkeiten zu referenzieren - aber normalerweise sollte deine App ja > nicht allzuviel brauchen und da musst du halt schauen, dass das aktuell > ist und zusammenpasst. Thema verfehlt! Es geht mir nicht um meine Applikationen, sondern 0815 turnkey images von beliebten Projekten wie nextcloud.
Laurenz schrieb: > Thema verfehlt! Es geht mir nicht um meine Applikationen, sondern 0815 > turnkey images von beliebten Projekten wie nextcloud. Tja, er hat aber schon alles gesagt. Du bist wohl etwas undankbar. https://hub.docker.com/_/nextcloud/tags Da könntest du Version 24 folgen wie er vorgeschlagen hat. Was aber auch egal ist, denn die Container führend etwaige Upgrades automatisch durch: Since all data is stored in volumes, nothing gets lost. The startup script will check for the version in your volume and the installed docker version. If it finds a mismatch, it automatically starts the upgrade process. Don't forget to add all the volumes to your new container, so it works as expected. PS: Nextcloud ist Rotz, genauso Docker. Wenn dir Sicherheit wichtig ist würde ich auf alles mögliche setzen, aber garantiert kein Docker. Wenn schon Container, dann etwas wie LXC. Docker läuft selbst als Root, viel zu riskant die Geschichte...
Onkel Ted schrieb: > Docker läuft selbst als Root, viel > zu riskant die Geschichte... systemd läuft selbst als Root, viel zu riskant die Geschichte... crond läuft selbst als Root, viel zu riskant die Geschichte... System IV init läuft selbst als Root, viel zu riskant die Geschichte... Soll ich weitermachen?
Oli Schulz schrieb: > Soll ich weitermachen? die wichtigsten vergessen: libvirtd läuft als root. libvirt_lxc läuft als root. lxd läuft als root.
> PS: Nextcloud ist Rotz, genauso Docker.
Alles was irgendwelche "Informatiker" zusammenklicken.
Laurenz schrieb: > Wie stellt man eigentlich Patchmanagement in Docker Containern / > Kubernetes Clustern sicher? Oh. Hans VMFreak <whatever>, bist Du wieder auf Deinem Kreuzzug gegen Docker, Kubernetes & Co.? Also wenn Du so ein Profi wärst, wie Du gerne behauptest, dann fielen Dir doch sicher aus dem Stehgreif zwanzig Lösungen dafür ein. > Nehme ich dagegen ein nacktes Debian oder CentOS/Rocky/RHEL, dann ...nimm das doch. Dann mußt Du weder dieses Forum mit Deinen Ergüssen erfreuen und kannst immer tief und ruhig schlafen.
... schrieb: >> PS: Nextcloud ist Rotz, genauso Docker. > > Alles was irgendwelche "Informatiker" zusammenklicken. Wohl eher Informalklicker höhöhö
Oli Schulz schrieb: > Onkel Ted schrieb: >> Docker läuft selbst als Root, viel >> zu riskant die Geschichte... > > systemd läuft selbst als Root, viel > zu riskant die Geschichte... > > crond läuft selbst als Root, viel > zu riskant die Geschichte... > > System IV init läuft selbst als Root, viel > zu riskant die Geschichte... > > Soll ich weitermachen? Die übernehmen alle die Isolation einer Anwendung vor anderen und dem Kernel? Interessant! Man sollte ggf. einmal einen Artikel über die Architektur von Docker und z.B. LXD gelesen haben und/oder sich diese einfach selbst genauer einmal anschauen. Eine Schwachstelle in den Isolationsmethoden des Kernels ist deutlich unwahrscheinlicher als eine im Docker Code.
Onkel Ted schrieb: > Eine Schwachstelle in den Isolationsmethoden des Kernels ist deutlich > unwahrscheinlicher als eine im Docker Code. Die Aussage ist ein bisschen... unklug. Container sind keine Sicherheitstechnik (was man wissen würde, wenn man die Dokumentationen gelesen hätte), und sie nutzen (und konfigurieren) nur die Schnittstellen des Linux-Kernels, insbesondere Namespaces sowie Control Groups. Der "Docker Code" gerät auch gar nicht mit der Aussenwelt in Kontakt. Hast Du diesmal vielleicht was Klügeres als im anderen Thread?
Was ist falsch mit euch? Ich will nicht darüber diskutieren, ob hier irgendwas als Root läuft. Ich will vernünftige Konzepte um die Aktualität von Docker Images sicherzustellen. Ein T. schrieb: > Laurenz schrieb: >> Wie stellt man eigentlich Patchmanagement in Docker Containern / >> Kubernetes Clustern sicher? > > Oh. Hans VMFreak <whatever>, bist Du wieder auf Deinem Kreuzzug > gegen Docker, Kubernetes & Co.? Also wenn Du so ein Profi wärst, wie Du > gerne behauptest, dann fielen Dir doch sicher aus dem Stehgreif zwanzig > Lösungen dafür ein. Du scheinst jemand zu sein, der oft aneckt. Ich habe ja keine Ahnung mit wem du hier im Forum so alles irgendwelche Differenzen hast, aber es scheint dich ja schwer getroffen zu haben. Vielleicht nennst du ja mal eine deiner zwanzig Lösungen. >> Nehme ich dagegen ein nacktes Debian oder CentOS/Rocky/RHEL, dann > > ...nimm das doch. Dann mußt Du weder dieses Forum mit Deinen Ergüssen > erfreuen und kannst immer tief und ruhig schlafen. Mein Gott. Das ist nicht das Thema. Damit habe ich viel Arbeit und die kann ich mir mit Turnkey Images ersparen. Also nenne mir doch bitte eine deiner 20 Lösungen und ich kann sogar mit fertigen Images ruhig schlafen. Wenn du das nicht kannst oder willst, dann bitte ich dich selber ruhig zu schlafen und deine Ergüsse in anderen Threads abzuladen. Du kannst mich dann auch gerne auf die Liste deiner Kreuzritter setzen. Onkel Ted schrieb: > Laurenz schrieb: >> Thema verfehlt! Es geht mir nicht um meine Applikationen, sondern 0815 >> turnkey images von beliebten Projekten wie nextcloud. > > Tja, er hat aber schon alles gesagt. Du bist wohl etwas undankbar. Du meintest wahrscheinlich den Post von Ernst B.? Der hat sich zeitlich mit meinem Post überschnitten. Ich bezog mich nur auf die erste Antwort. Εrnst B. schrieb: > Laurenz schrieb: >> Ich muss also den Tag fix auf die >> Version setzen, erhalte dann aber für den Tag keine Sicherheitsupdates >> mehr. So ist das doch alles Murks! > > "gute" Images bieten da Tags an, die auch auf kompatible Versionen mit > Sicherheits-Updates passen. > > z.B. mit "postgres:12" kriegst du kein ungefragtes Update auf 13 oder > 14, sondern die aktuelle 12.12er Version. Im Unterschied zu > "postgres:12.12" kriegst du aber ein Update, sollte eine 12.13er-Version > erscheinen. Ja, das ist sinnvoll. Ich habe da allerdings zwei Probleme. Vielleicht hat da jemand eine gute Lösung für. Erstens bekomme ich nicht mit, falls irgendwann Postgres 12 keine Updates mehr erhält. Ich bräuchte also eine Art Überwachung, ob ein Image in den letzen x Tagen aktualisiert wurde. Zweitens muss ich die Updates ja auch ausrollen. Ich muss also irgendwie einen automatischen Check laufen lassen und danach einen konkreten Tag setzen, da im Kubernetes Cluster ja sonst kein Rollout startet oder ein redeploy Auslösen. Gibt es da Tools für? > Trotzdem: > > Laurenz schrieb: >> Muss ich alle meine Images dann selber bauen? > > Ja. Mehr oder weniger. Kannst auch irgendwo eine Grenze ziehen, welchen > Projekten du zutraust, zeitnah Sicherheitsupdates zu integrieren, und ab > welcher Ebene du selber baust. > > Z.B. den Debian-Basis-Images vertrauen, darauf aufbauende Dockerfiles > selber bauen lassen. Ich halte es bisher so, dass ich ausschließlich offizielle Images der jeweiligen Projekte verwende. Ich denke, dass das ein ganz guter Kompromiss ist. Speziellere Dinge baue ich mit einer CI/CD Pipeline aus genannten Gründen in Gitlab selbst. Wenn aber ein Image offensichtlich keine Updates für das Betriebssystem erhält, ist es raus.
Karl Käfer schrieb: > Container sind keine Sicherheitstechnik Das schreibst du jetzt, hab ich aber nie geschrieben.
Laurenz schrieb: > Ich muss also irgendwie > einen automatischen Check laufen lassen und danach einen konkreten Tag > setzen, da im Kubernetes Cluster ja sonst kein Rollout startet oder ein > redeploy Auslösen. Gibt es da Tools für? Ich setze da seit einiger Zeit auf https://keel.sh/. Pro Deployment konfiguriere ich da jeweils mit Annotationen ein Updateintervall, welches alle X Tage auf eine neue Minor Version prüft und diese dann automatisch einspielt bzw. mir Bescheid gibt (Je nach Wichtigkeit der Anwendung). Für interne Anwendungen kann zusätzlich auch ein Redeployment per Webhook ausgelöst werden (z.B. aus einem CI/CD Job). Zusätzlich kann man sich mit Keel auch Benachrichtigungen senden lassen, wenn z.B. ein Update ansteht oder nachdem es eingespielt wurde. Klappt bislang sehr gut, nur muss man sich natürlich auch auf die Quelle des Images verlassen können.
> Ich will vernünftige Konzepte um die > Aktualität von Docker Images sicherzustellen Nimm halt Solaris Sparse Zonen. Die kriegen automatisch ihr Fett äh Update weg.
Ntldr -. schrieb: > Ich setze da seit einiger Zeit auf https://keel.sh/. > > Pro Deployment konfiguriere ich da jeweils mit Annotationen ein > Updateintervall, welches alle X Tage auf eine neue Minor Version prüft > und diese dann automatisch einspielt bzw. mir Bescheid gibt (Je nach > Wichtigkeit der Anwendung). Für interne Anwendungen kann zusätzlich auch > ein Redeployment per Webhook ausgelöst werden (z.B. aus einem CI/CD > Job). Das sieht sehr interessant aus. Werde ich mir auf jeden Fall mal ansehen. Dann fehlt mir eigentlich nur noch ein Audit Tool, um das Alter der deployten Images zu überwachen.
Ein T. schrieb: > Oh. Hans VMFreak <whatever>, bist Du wieder auf Deinem Kreuzzug > gegen Docker, Kubernetes & Co.? Also wenn Du so ein Profi wärst, wie Du > gerne behauptest, dann fielen Dir doch sicher aus dem Stehgreif zwanzig > Lösungen dafür ein. Ach sieh an, der Schaumschläger ist wieder da. Laurenz schrieb: > Du scheinst jemand zu sein, der oft aneckt. Ich habe ja keine Ahnung mit > wem du hier im Forum so alles irgendwelche Differenzen hast, aber es > scheint dich ja schwer getroffen zu haben. Vielleicht nennst du ja mal > eine deiner zwanzig Lösungen. Der hat keine einzige Lösung. Keine Ahnung, ob er Docker und Kubernetes wirklich so durch die rosa Blümchenbrille sieht oder er einfach nur ein Troll ist. Aber mit konkreten Problemen konfrontiert kontert er bestenfalls mit unpassenden Links. Den kannst du getrost ignorieren.
Habe keel jetzt im Einsatz. Scheint soweit nun stabil zu funktionieren. Auch den Webhook für die Integration in CI/CD Pipelines ist sehr praktisch. Was noch fehlt ist ein Audit, welche Images zu alt sind, aber da teste ich schon. Huch schrieb: > Laurenz schrieb: >> Du scheinst jemand zu sein, der oft aneckt. Ich habe ja keine Ahnung mit >> wem du hier im Forum so alles irgendwelche Differenzen hast, aber es >> scheint dich ja schwer getroffen zu haben. Vielleicht nennst du ja mal >> eine deiner zwanzig Lösungen. > > Der hat keine einzige Lösung. Keine Ahnung, ob er Docker und Kubernetes > wirklich so durch die rosa Blümchenbrille sieht oder er einfach nur ein > Troll ist. Aber mit konkreten Problemen konfrontiert kontert er > bestenfalls mit unpassenden Links. Den kannst du getrost ignorieren. Hast recht, der hatte außer heißer Luft echt nichts beizutragen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.