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?
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.
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.
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.
