 Willkommen beim RC3 zurück auf dem Stream von ChaosZone.tv. Hier geht es gleich weiter mit dem nächsten Vortrag und noch ein kleiner Hinweis. Dieser Vortrag wird übersetzt werden. So a short notice for the non-German speakers. This talk will be translated into English. You should find the switching button to the other language in the below video. Okay, ihr könnt Fragen stellen zu diesem Vortrag. Das ist der Vortrag. Der Titel des Vortrags lautet DevOps Disaster 3.1 Den Zahlen habe ich das Gefühl, ich erkenne ein Muster. Und das ist auch so, denn the same procedure as last year. Jetzt neu mit eigenem Dockercontainer. Und wir heißen Willkommen, Stefan und viel Spaß mit dem Vortrag. Hallo und guten Tag. Ich fies nur Übergang. Ich hoffe, ich bin im Bild. Das ist mit den ganz vielen Fenstern. Und der neuen Situation für uns alle ein bisschen aufregend auch für mich. Wir kommen bei DevOps Disasters angekündigt als 3.1. Jetzt veröffentlicht. Ich habe mir noch mal Mühe gegeben als 3.11, weil wir haben ein TCP-Stay hier. Und wir können miteinander kommunizieren. Wir wollen gerne die Möglichkeit nutzen, die wir haben. Und nochmal geschrieben, wie ihr jetzt teilnehmen könnt, wie ihr direkt mitmachen könnt. Es gibt ein IAC Channel, kommt da gerne rein. Ich habe auch auf der Webseite www.devopsdisasters.net. Ich finde ihr auch ein Webchat. Unter dem Video, wenn ihr über die MediaCCD unterwegs seid, ist der Webchat auch drin. Und was ich auch schon gemacht habe, das macht man ja eigentlich nicht. Ich habe es dieses Jahr mal gemacht. Schon die Slides veröffentlicht. Falls ihr also wirklich eine schlechte Internetverbindung habt und die Memes in echt sehen wollt, könnt ihr die Slides gerne live mitgucken. Die liegen bei Google. Genau. Ich erzähle mal ein bisschen was, was ihr in der Zwischenzeit in den IAC finden könnt. Oder in der Webchat, falls ihr wollt. Wer ich bin, ich arbeite in Leipzig in einem Tech-Kollektiv. Und wir machen für größere NGOs die Technik. Und ich bin in der Operations-Abteilung dafür zuständig, dass die Sachen, die unsere Dev-Abteilung bauen, dann tatsächlich auch in die Welt kommen und laufen. Das führt dazu, dass ich relativ viel komische Sachen sehe. Nicht, weil unsere Devs komische Sachen bauen. Die Devs bauen sehr schöne Sachen. Wir reden auch sehr viel miteinander. Aber in dieser ganzen Welt gibt es ein Haufen Zeug. Und einmal im Jahr herre ich alles zusammen. Und halte diesen Talk nun zum dritten Mal. Steigen wir mal ein. Was bisher geschah. Ein kurzer Rückblick auf die letzten Jahre. Wo kommt das eigentlich her? Was ich hier tue, ich hatte es schon gesagt. Ich arbeite im IT-Kollektiv. Wir haben dort ein Chat, wo wir miteinander reden. Wir haben hier ein Channel, der eigentlich mal dazu da war, zu sagen, wir wollen unsere Fehlerkultur offen kommunizieren. Wir wollen offen sagen, wenn uns was schief gegangen ist. Und dann freuen sich alle. Ja, wir haben die Production-Datenbank gelöscht. Jemand muss sie ganz machen. Warum eigentlich? Weil das irgendwie sich dazu entwickelt hat. Auch alles zu verreißen, was da draußen in dieser Welt komisch ist, passiert. Und das Schöne daran ist, dass ich am Ende des Jahres einfach nur einmal da durchkehren muss. Und dann kann ich diesen tollen Talk mit euch zusammen machen. Eine ganz wichtige Geschichte in unserem Fail-Channel ist, Lessons to Learn, das steht da auch oben drüber. Das ganz Wichtige ist, daraus zu lernen. Also zu gucken, wie geht es besser. Ich will euch also nicht nur zeigen, was macht man komisch da draußen in der Welt, sondern was kann man irgendwie tun, damit es besser geht. Auch nochmal ganz kurz. Rückblick, wo haben wir irgendwie die letzten Jahre alles drüber geredet? Falls es euch das interessiert, die Slides sind auch auf der Webseite. Wir haben hier die letzten Räume angeguckt, was man da alles falsch machen kann. Prozessmanagement, also so Prozesse hinten rausforken, so wie man eigentlich Software konfiguriert. Persistenz, wie persistiert man eigentlich Daten, auch an verteilten Systemen. High Availability haben wir uns angeschaut. Packaging und Installer, also wie kommt eigentlich Software in die Welt? Continuous Integration, continuous delivery Systeme und Hype Trains. Ich zeige euch das deswegen, weil ich nichts anderes machen werde, als das jetzt nochmal durchzugehen, was in der Welt gefordert ist. Mit dem kleinen Schwerpunkt dieses Jahr auf Hype Train. Docker, ich hatte es ja schon angekündigt. Also, reines Jahr 2020. Was ist passiert? Im Bereich Logging hatten wir ein schönes, schöne Situation, die schön gezeigt hat, dass in dieser Docker-Welt doch eine ganze Menge noch unbeantwortet ist. Und zwar geht es um Folgendes. Wir wollen, das ist die Challenge, die wir erreichen wollen, wir wollen periodische Tasks in Docker ausführen. Das heißt, es gibt irgendwie Docker-Container da draußen. Und die Aufgabe ist, regelmäßig alle fünf Minuten, alle zehn Minuten, einmal die Stunde, irgendwas darin zu tun. In der alten Welt, wo wir noch keinen Docker hatten, hatten wir dafür Kron. Das kann man also tun. Eine Möglichkeit ist, man nimmt sich diese Frameworks, diese Worker-Frameworks, die wir da draußen haben, für assenkrone Prozesse. Sidekick ist in Ruby relativ weit verbreitet. Und die haben zum Teil Erweiterungen, zum Beispiel diesen Scheduler für Sidekick oder den Beat für Celerity. Und dann startet man einfach ein Container mit, die assenkrone Jobs losfeuern, funktioniert. Mal mehr, mal weniger gut. Mit dem Sidekick Scheduler hatten wir unsere Probleme. Celerity Beat hat bis jetzt einen ganz guten Eindruck gemacht. Eine zweite Möglichkeit ist, auch Kubernetes kann inzwischen Grundjobs, Ihnen ist aufgefallen, dass in Docker ja irgendwie auch so was wie Grundjobs abgebildet werden müssen. Wer man Kubernetes benutzt, wir tun das zum Beispiel nicht. Und wenn gar nichts hilft, muss man eben so einen Kron, die man in so einen Container reinpacken, weil wo soll es denn herkommen? Es gehört zur Anwendung, also muss man irgendwie so einen Kron, die man reinpacken, der dann in die Jobs abfeuert. Weil das Teil der Anwendung muss halt in den Docker-Container. Große Frage, wir haben es gemacht, wir haben tatsächlich Kronendemons in diese Docker-Container reingepackt und dann war die Frage, wo kommen wir denn jetzt eigentlich an die Logs hin? Das ist die Situation. Docker lockt alles, was nach Standard Out ausgegeben wird. Und wer sich ein bisschen auskennt mit Kron weiß, dass Kron alles per Mail schickt, weil auf Standard Out guckt ja niemand. Ein schönes Beispiel, dass auch richtig alte Software, die seit Jahren, seit 20, 30 Jahren Betriebs, bis noch komische Sachen macht, wer hätte gedacht, dass man irgendwie vielleicht auch mal nach SysLock oder sonst woanders hinlocken mag. Es gibt ein Bug Report für das Problem von 2018. Der sagt, es wäre doch irgendwie total toll, wenn man irgendwie Docker im Vordergrund laufen lässt, dass man vielleicht irgendwie nach SysLock oder Standard Out oder irgendwo anders hinschiebt. Der ist halt offen, wird unbeantwortet. Hat man halt ein Problem? Kommt man halt nicht an seine Logs ran. Wir haben tatsächlich, der Chat schreibt, man könnte SystemD aus Olin. Natürlich. Auch hier nochmal die Folie, die haben die Leute, die die letzten Jahre zugeguckt haben, schon mal gesehen. Wenn ihr Logging machen wollt, bitte benutzt die Bibliotheken, die es dafür gibt. Logging ist ein gelöstes Problem. Das muss man sich nicht nur einfallen lassen. Man muss nichts per Mail schicken oder irgendwelche Files schreiben. Warum nicht haben wir uns die letzten Jahre schon mal angeguckt. Mützt die Bibliotheken, die eure Programmiersprache hergeben. Macht das konfigurierbar, dass man irgendwie als Operations Manager sich aussuchen kann, was dir sinnvoll ist und wenn wirklich mal gar nichts geht, dann schreibt den Kram nach Standard Out oder Standard Error. Aber fangt nicht an, soll euch in jeder Anwendung ein neues Logging-Lösung auszudenken. Der grudesten Kram haben wir schon gesehen. Bis zu, wir locken in die Datenbank unserer Anwendung und schreiben ein Interface. Auch das haben wir schon gesehen. Konfig Handling. Auch da, Docker, immer interessanter mit dem, was passiert. Die Antwort von Docker eigentlich ist Konfig Handling, bitte über Environment Variabeln. Also von außen irgendwo Environment Variabeln setzen und das ist dann die Konfiguration. Das Problem daran, das sind Strings und nichts anderes als Strings und da kann doch eine ganze Menge schiefgehen. Das sind vor allem keine Booleans. Das hatten wir letztes Jahr schon mal im Talk, nochmal ganz kurz, damit das Problem klar wird. Das, was in Enzybil ein True oder False ist, ist noch lange kein String True oder False. Wird gern mal auch groß und klein umgeschrieben. Jammel, Peiten, irgendwas gepasst und gekastet. Und das, was dann am Ende in dem Environment landet, als Boolean muss nicht das sein, was man sich schön gedacht hat. Es gibt schöne Beispiele, die wir auch erlebt haben, dass man da irgendwas als True setzen wollte und das noch lange kein True geworden ist, weil am Ende läuft eben eine Ruby-Applikation, die ist eben genau wieder anders zurückpasst. Und was auch ein Problem ist, es geht natürlich keine komplexe Konfigurationen rein. Es gehen einfach nur einfache Werte rein. Das heißt, sobald man z.B. so etwas wie gern dickt hätte, dann ist es schon vorbei. Und was wir tatsächlich schon gesehen haben, ist, dass Leute anfangen, Jason in die Environments Strings reinzuschreiben und auf der Gegenseite dann wieder zu pasen. Was wir relativ häufig sehen, in dem letzten Jahr sehr viel gesehen haben, ist, wir haben noch da eine Datenbank in unserer Anwendung. Kann man doch die Konfiguration da reinschreiben. Das hatten wir auch die letzten Mal schon. Konfiguration in Datenbanken. Oh mein Gott, nein, nicht machen. Wir haben so alles angefangen, Konfiguration in eigenen Datenbanken zu schreiben. Kurzer Überblick. So ein Chatprogramm, Slack Alternative. Sensor Go, also ein Monitoring Programm, hat damit angefangen. Und das Highlight in diesem Jahr, tatsächlich haben wir uns noch mal gesehen, Influx DB2 hat angefangen, Konfig in die eigene Datenbank zu schreiben. Wer sich so ein bisschen mit Influx DB auskennt, wird sich sagen, moment mal. Influx DB ist doch eine Time Series Datenbank. Das sind doch Time Series drin in dieser Datenbank. Aber klar, doch schreiben wir Influx DB Konfiguration in eine Time Series Datenbank. Ich habe das mal aus der Doku genommen. Es geht also darum, auf Influx DB einen Check einzurichten. Also irgendwie auf den Metriken zu alarmieren, also Metriken zu checken und zu alarmieren. Das ist wirklich der Weg, den sich Influx DB dafür ausgedacht hat. Das heißt, wir haben eine ganz normale Metrik. Da ist mal eine Query drauflaufen. Das Ergebnis dieser Query landet in der neuen Metrik. Darauf wird eine Check Rule angewandt. Das Ergebnis dieser Check Rule landet in der neuen Metrik. Und dann wird am Ende irgendein Alarm gedriggert. Das ist irgendwie ein schöner Fall von, wenn ich einen Hammer habe, ist alles ein Nagel. Auch Config Handling hatten das letzte Mal schon. Hier noch einmal die Zusammenfassung. Config Handling ist ein gelöstes Problem. Also so eine Sache wie, wir laden dann mal ganz am Anfang unseres Programms irgendwie PHP-Code oder Python-Code rein. Und das ist dann unsere Config. Django macht das zum Beispiel PHP. Wenn wir machen das auch sehr gerne. Nein, Config ist kein Code. Config sind auch keine Nutzdaten oder End-Userdaten. Die gehören auch nicht in die Datenbank. Es gibt ein Haufen Config-Parser da draußen in der Welt, wo ihr in die Style, ja mit Style irgendwas da in Config schreiben könnt. Für Docker gelten die End-Fars. Jetzt löst das alles nicht unser Problem, was ich angesprochen habe. Docker hat eigentlich noch nicht so eine schöne Antwort darauf. Eine schöne Ecke für neue Technologien machen halt neue Fragen auf. Was sich ein bisschen abzeichnet ist, neue Technologien halt auch zu nutzen. Also die Key Value Stores, die es da draußen gibt. ICD-Konsul. Und dann den Anwendung eben beizubringen. Das tatsächlich zu lesen. Das hat dann auch den Vorteil, dass wir früher oder später dann irgendwie die Module kriegen werden, um mit Enzybil oder Saltstack da rein zu konfigurieren. Weil das ist ja auch immer ein Problem, Config in Datenbank zu schreiben. Meist auch immer, dass wir eigentlich nicht mehr automatisiert deployen können. Weil wir irgendwie nicht automatisiert oder nicht gut automatisiert herankommen, oder so eine Lösung schreiben müssen, wie wir jetzt die Anwendung konfigurieren. Ein schöneres Beispiel aus dem Bereich High Availability, was wir dieses Jahr gesehen haben. Ich sage mal noch nicht, welche Software das gewesen ist. Da hat tatsächlich eine Software aus dem Bereich High Availability es für eine gute Idee gehalten, eine State Machine zu bauen. Und zwar eine Distributed State Machine. Und zwar nicht nur über verschiedenen Surfer, sondern auch über Surfer und Clients hinweg. Ganz große Idee, weiß jemand, was für eine Software das sein könnte. Ihr könnt ja mal in IAC schreiben. Ich habe einen kurzen Blick drauf, falls jemand das einfällt, was das sein könnte. Ich sehe noch nichts. Apache's Zookeeper war das. Warum sind wir dabei? Sind wir bei diesem Problem vorbeigekommen? Wir haben überlegt, müssen wir eigentlich unsere Kafka Cluster back up? Da laufen wir immer in Daten durch. Wir haben hier die Message Queues von einem Cluster Status. Wir sind darauf gekommen, dass es eigentlich nicht möglich ist, im sinnvollen Backup dieses Kafka Clusters anzulegen. Was auch eine sehr interessante Erkenntnis ist, auch wieder schön aus der Ecke. Neue Technologien und andere und andere uns. Wenn man also Apache Kafka back upen will, muss man eigentlich dafür sorgen, dass man alle Messages mitschreibt und das ganze System replayfähig bekommt. Also jeder Impotent zu bauen, dass ein Nachricht mehrmals eingehen kann, macht einen Haufen neue Fragen auf. Ich bin mir nicht sicher, ob irgendjemand auf dieser Welt das wirklich gelöst hat. Message Queues nutze man einfach. Als wir das gesehen haben, haben wir ungefähr so geguckt, wie dieser bekannte Mensch hier. Auch zur High Availability nochmal. Die Erkenntnisse aus den letzten Jahren. High Availability fügt immer neue Komplexität aus. Man muss immer gucken, was ist eigentlich hier wirklich Haar? Welcher Teil ist es eben auch nicht? Bei den Beispiel Suchkeeper kann man das sehr schön sehen. Klar kann da mal ein Surfer ausfallen, wenn dann aber irgendwie klein wechselnd oder State nicht mehr da ist, dann steht man eben auch im Dreck. Das Cup Theorem taucht da immer wieder auf. Was ist also beweisbar unmöglich? Eigenschaften, die man eigentlich haben, die wir gleichzeitig zu haben. Genau, und der letzte Teil, was ist ja eigentlich Haar, trifft auch immer wieder auf. Packaging und Installer hatten wir relativ viel dieses Jahr. Irgendwie kommen gerade alle auf die Idee, dass man irgendwie sein eigener Installer schreiben muss. Hat man letztes Jahr ja auch schon mal dieses Jahr, ist es nicht besser geworden. Kurze Liste, was uns alles über den Weg gelaufen ist. Enzybil hat es angefangen, mit Enzybil Collections ein neues Format zu entwickeln. Mit der neuen Enzybil Version kommt es mit und haben gesagt, Pie Pie Installationen machen sie vielleicht gar nicht mehr. Das ist vor ohnehin schon immer ein Problem. Macht es entweder mit der Hand oder nimmt unser RPM Package. Ganz toll, ja. Enzybil ist von Redhead gekauft worden. So merkt man es dann. Poetry ist mir begegnet vor ungefähr 2 Monaten. Ich muss ganz ehrlich sagen, ich habe nicht verstanden, warum es Poetry gibt. Kann sein, dass ich mich einfach, dass ich es tatsächlich nicht verstanden habe und dass es einen guten Grund gibt, den ich nicht gesehen habe. Poetry ist also ein neuer Paketmanager für Python, wobei ich sagen muss, wir haben mit PIP und dem ganzen Universum rundherum eigentlich einen stabilen Paketmanager, der weit verbreitet ist, der gut funktioniert, seit Jahren etabliert ist. Als ich das Projekt gesehen habe, hatte ich das Gefühl, dass da irgendjemand aus der JavaScript-NPM-Welt oder aus der Bundlerwelt um die Ecke kommt und irgendwie nicht verstanden hat, dass das Mindset ein bisschen anders ist in Python und sich entschlossen hat, dass er doch irgendwie die NPM-Welt nochmal in Python nachbauen will. Warum auch immer. Und das Witzigste daran, was ich gesehen habe, ist, es gibt ein Kommando Poetry Export. Das macht daraus ein Requirements.txt-File, damit man es dann mit PIP installieren kann. Ist mir irgendwie tatsächlich unklageblieben, warum jemand um die Ecke kommt und nochmal ein Installer für Python schreibt. Ich sehe hier auch gerade im Chat sehr schön, warum braucht man ein Installer? Jeder hat doch Python nach Bash. Auch das ist natürlich weit verbreitet. Wir kriegen jedes Mal die Krise, wenn wir es sehen. Anakonda, wie ihr es nicht kennt, das ist eine Distribution, die im KI-Umfeld relativ weit verbreitet ist. Geht es darum eigentlich im Großen und Ganzen die Python-Pakete zusammen zu schmeißen und zusammen zu schnüren, die da draußen irgendwie immer das KI zu tun haben. Ich habe auch da nicht wirklich verstanden, warum es das gibt, weil mit PIP kann man das auch alles installieren. Die Begründung dazu ist, dass man quasi, wenn man mit PIP installiert, manchmal was gegen C-Linken muss, dann EBC, herrder Brauch, was aber bei Python mit den Wiels inzwischen automatisch passiert. Was sie da machen ist, sie bauen also mit Anakonda die ganzen Banneries schon mal selbst vor. Es haben sie das Problem, dass sie das ja irgendwie linken müssen gegen das Environmentum rum. Ihre Lösung dafür ist, ein komplett eigenes Environment mitzubringen und in den Pass einzuflechten vor den System-Libraries. Das heißt, wir haben irgendwie ein komplett eigenes Environment, inklusive TAR, CURL, Liptool, OpenSSL und alles, was da drin noch kommt. Und das kommt vor den System-Paketen. Das heißt, alle Updates, die ihr mit UPD oder RPM oder was ihr auch immer benutzt, einspielt, kommen dann eben nicht mehr an. Dafür Applaus für die Ansätze. Einfach nochmal. Ein Paketmanager zum dritten Mal zu entwickeln. Ich sehe gerade im Chat, dass es Fans von Poetry gibt. Kommt gerne hinterher noch mal in den JETZI rein zum Quatsch und erklärt es mir. Ich bin da offen. Ich habe es tatsächlich, vielleicht einfach nicht verstanden. Ein anderes Beispiel aus dem Bereich Packaging und Installer. Minio hatten wir auch schon mal in den letzten Jahren. Minio ist ein Open-Source-SS3-Alternative. Kann man also quasi S3 bei sich im Rechenzentrum nachbauen, ohne dass man zu Amazon muss. Benutzen wir relativ viel. Das Problem bei Minio ist, die Releasen relativ häufig, ich habe mir mal aus den letzten 2 Wochen, die Release-Pipeline. Wir haben also am 10.12. ein Release. Wir haben am 12.12. ein Release. Am 16. kann das nächste. Am 18. hat man noch eins. 23. noch eins. Und für jedes dieser Releases müssen wir natürlich eine ordentliche Qualitätssicherung machen. Das heißt, irgendwie rollen wir das auf Staging aus. Wir gucken, ob unsere Software noch funktioniert. Wir müssen irgendwie ein Release-Fenster für Produktion finden, auf Produktion ausrollen. Es kommt regelmäßig vor, dass wir ein Release in Produktion endlich haben und unser Alerting, unser Update-Monitoring schon wieder anschlägt, weil in dem Moment, wo wir das Produktion-Release rausgeschoben haben, schon das nächste Release wieder da ist. Und die große Frage ist ja immer, wir müssen ja gar nicht jedes Release haben. Es reicht ja irgendwie, Security-Releases mitzunehmen. Man kann ja die Feature-Releases durch aus Stück für Stück nachziehen. Das ist dann Security-relevant. Und wenn es keiner ranschreibt, wissen wir es eben nicht. Und wenn wir es nicht wissen, ist es im Zweifel Security-relevant. Woher sollen wir es denn sonst wissen? Und zwar müssen wir es eben abdecken. Und das ist genau das Problem bei Minio. Minio schreibt es eben nicht dran. Die hauen das eben einfach raus. Daher eine ganz klare Bitte an euch. Wenn ihr irgendwie Software baut, verlasst euch bitte irgendein Weg einfallen, dass wir erkennen können, was von dem Zeug ist Security-relevant und einfach nur Feature-Releases, weil Release-earlieries oftens führt dann einfach dazu, dass wir ungefähr den ganzen Tag das machen. Auf der anderen Seite immerhin gibt es Minio-Pakete. Wir hatten einen Fall, dass wir einen Doku-Wiki-Plug-In installieren wollten und da einfach nur ein Repo vorgefunden haben. Wir haben einfach mal ganz kurz über GitHub eine Anfrage gemacht, ob es nicht möglich ist, zumindest davon Release zu machen. Bei GitHub ist das ja kein Problem. Und das ist die Antwort, die wir gekriegt haben. Das ist so ein simples Plug-in und das mache ich so selten. Genau zweimal in den letzten zehn Jahren. Alles, was per GitHub auf dem Master Branch gepusht wird, ist eben Stabil Release. Das finde ich ganz schön sportliche Aussage. Aber auch das gibt es in dieser Welt. Kann man so sehen. Die Wahrscheinlichkeit, dass das knallt, ist auch relativ hoch. Auch dafür, Packaging und Installer, nochmal die Folie, wie geht es richtig? Packaging und Installer sind ein gelöstes Problem. Er findet das Rad nicht neu. Es gibt bestehende Packaging-Formate für alle Programmiersprachen da draußen. Wenn nicht für die Programmiersprachen, dann auch für die Distribution. Die sind manchmal auch ein bisschen komisch, auch mit Jahren oder Komposer. Ärgern wir uns rum. Und trotzdem gibt es die. Es wird an einem Strang geguckt, wo Sachen schieflaufen baut. Um Gottes Willen kann einer eigenen Installer sein, dass das schief geht, ist nahe 100%. Das war alles das, was wir die letzten Jahre aus den bekannten Kategorien hatten. Gucken wir uns mal an, was in der Dockerwelt so los ist. Das Bild, was ich da oben gefunden habe, trifft ungefähr unsere Erfahrungen. Wir werden es uns im Detail angucken. Warum ist das relevant? Es ist inzwischen tatsächlich so, dass egal, wo man hinguckt, egal welches Projekt man sich anschaut, dass man um die Ecke kommt und sagt, hier ist unser Docker-Container. Im besten Fall findet man noch ein Go-Binary irgendwo. Oder die Geschichten, die mit Snap und Flatback um die Ecke kommen. Aber jeder meint, da hatte ich ein Docker-Container und damit wäre das Problem gelöst. Ganz von vorne nochmal anfangen. Warum haben wir eigentlich Docker? Ich bin mal auf die Seite gegangen, tatsächlich die Docker-Startseite. Da hat man versucht, auf der Startseite die Begründung zu finden. Das Docker-Öbel ist cool. Und dass das alle benutzen und dass das total fetzt. Aber warum man das benutzt, stand da irgendwie nur in einem einzigen Satz. Und das ist der, den ich da oben geschrieben habe. Wir haben Container, damit wir standardisierte Einheiten haben, um Software vom Environment zu isolieren. Das ist erstmal ganz cool. Drei Sachen sind da drin wichtig. Es gibt also eine App, also irgendein Stück Software. Es gibt ein Environment und die beiden sollen voneinander isoliert werden. Was gern übersehen wird, und ich glaube, das ist das Hauptproblem, bevor wir überhaupt anfangen, über so etwas wie Kubernetes ein Code zu reden. Es ist eben nicht nur die App, die man da drin in einem Docker-Container hat, sondern es ist eben auch die Laufzeit-Umgebung der App. Das heißt, es geht nicht nur darum, dass ich meine Ruby, Rails, Django, irgendwas, die Applikation in den Container reinkriege, sondern in den Container ist eine ganze Menge mehr. Das heißt, das gehört dazu, zu dem, was in dem Container steckt. Environment heißt, wir haben irgendeine Infrastruktur aus den Rummen. Das ist uns erstmal egal. Ich werde heute auch nicht auf Kubernetes ein Code eingehen. Wir werden einfach nur die Docker-Container angucken. Und die soll eben isoliert werden, soweit so gut. Das habe ich mir mal ein ganz einfaches Beispiel genommen. Da ist nicht mal Kommando drin. Also wir nehmen einfach nur unter 18, 14, 15, 15, 15. Also wir nehmen einfach nur unter 18, 14 Base-Image. Das ist das offizielle unter 18, 14 Base-Image. Legen da zwei Ordner an und geben uns die Ordner wieder aus. Nichts Spannendes passiert. Sieht jemand ein Problem? Ich kriege noch nichts. Also dass alle unter Docker leiden, sehe ich noch nicht, dass es ein Problem gibt. Der entscheidende Punkt ist, das hat es eben schon gesagt, es gibt auch die Laufzeit-Umgebung. Und in dieser Laufzeit-Umgebung können Sicherheitslücken auftreten. Kurzes Spiel. Versuchen wir das mal im IOS-Seedjet mal gucken, ob das funktioniert. Wer von euch benutzt Docker, jeder bitte mal, wenn ihr Docker benutzt, eine Eins einfach eingeben und in den IOS-Seedjet schreiben, mal schauen, was jetzt kommt. Komm, eine ganze Menge Einzelnen angeflogen. Sehr schön. Ich sehe, ihr seid da, ihr seht noch zu. Ihr seht aus, wenn es ein Security-Fix im Base-Image gibt, dann macht bitte mal eine 2. Ich warte kurz. Ich habe eine 2 gesehen. Noch eine 2, sehr schön. Es ist großartig. Ich kriege gerade von der Regie angesagt, ich soll ein bisschen langsamer machen, weil wir Latents drin haben. Wir kommen tatsächlich 2, das ist wirklich was Neues dieses Jahr. Anom Talks auch schon mal. Es ist das erste Mal das 2. Und tatsächlich relativ viele. Sehr schön. Es hat sich was getan. Versuchen wir mal die dritte Frage noch. Jetzt mit der 3, bitte antworten. Wer von euch monitort denn die laufenden Container, ob es neue Vulnerabilities in den Base-Images gibt? Mal ganz kurz. Zähle mal. Ganz in Ruhe bis 10, dass ihr die Chance habt, vielleicht an der 3 zu schreiben. Ich bin ja schon total froh, dass es neue 2 gibt. Ah, eine 3. Sehr schön. Wir werden besser über die Jahre. Den Talk machen wir noch 5-mal, dann macht ihr das alles. Sehr gut. Für das Beispiel, was wir davor gesehen haben, also dieser ganz einfache Container, einfach nur Ubuntu 18.4 nehmen, hochladen. Ich habe das tatsächlich vorgestern probiert, so gebaut. Ich habe gar nicht so viel Werbung dafür machen, aber das ist ein Security-Scanal, kann man Images hochladen, die gucken einfach rein in das App, also in dem Paketmanager. Die haben nochmal eben 32 Vulnerabilities gefunden. Das heißt, selbst der billige Container, den ich euch eben gezeigt hat, hat 32 Security-Vulnerabilities. Und die entscheidende Erkenntnis ist, und das ist das, was wirklich viele Leute noch nicht auf dem Schirm haben, wenn ihr anderen Leuten Docker-Container in die Hand geht für eure Software, dann seid ihr nicht nur verantwortlich, der drin ist, sondern ihr seid eben auch für die Laufzeit verantwortlich. Also für die Laufzeit-Umgebung, für das Linux, was da drin steckt. Ihr gebt Leuten ein Linux-Server im weitesten Sinne in die Hand. Auch das nochmal ganz deutlich, ich glaube das ist die wichtigste Erkenntnis, die viele Leute noch nicht verstanden haben, die anderen Leuten Docker-Container in die Hand geben. Ihr seid auch für die Laufzeit-Umgebung verantwortlich. Das heißt, ihr müsstet eigentlich alle zwei, drei Tage ein neues Image oder auch die Updates, die ihr normalerweise für eure Linux-Veränderung bekommt. Wir haben letzten Sommer, dass wir wissen wollen, wie sieht das eigentlich aus mit den Base-Images, kann man den eigentlich vertrauen. Wir haben die Standard-Base-Images genommen und haben die mal zu Keier hochgeladen, genau so ein billiges Image, was überhaupt nicht macht. Einfach mal hochgeladen und gucken, was da rauskommt. Die Zahlen, die sind jetzt nicht ganz akkurat, wenn ihr das heute macht, werdet ihr leicht andere Zahlen bekommen. Es war aber nie so, dass alles in Ordnung war. Es war immer gruselig. Ubuntu 8.4 haben wir stand heute. Wie gesagt, der Container liegt da schon ein bisschen. 58 Vulnerabilities, 27 sind, gibt es Patches dafür. Noch mal, als wir das Initial gemacht haben, sah das auch nicht viel besser aus. Devian 10 Base-Image, 81 Vulnerabilities und 20 Patches. Interessant ist, dass es für Ubuntu tatsächlich mehr Patches gibt, als für Devian. Das heißt, Ubuntu scheint mehr Updates auszuliefern. CentOS haben wir probiert, haben wir gleich 133 Vulnerabilities drin. Immerhin gibt es für alle auch ein Patch. Das heißt, wir könnten da den Docker Container Initial erst mal updaten. Elpine relativ weit verwendet. Auch wir hatten lange Elpine. Das Problem bei Elpine ist, die veröffentlichen zwar täglich neue Container, aber die veröffentlichen, die Daten zu dem, was da gefixt wird, also zu den Vulnerabilities, auch nur, wenn sie den Fix dafür haben. Das heißt, die sehen zwar relativ gut aus, wenn man die durch so einen Scanner laufen lässt, aber die kommen einfach überhaupt nicht hinterher, was die Patches angeht, weil sie nämlich nicht veröffentlichen, dass sie ein Problem haben. Und das ist tatsächlich der Grund, wir sind weggegangen von Elpine, wir waren sehr lange auf Elpine. Unsere Ruby Developer, die kam ständig zu uns und haben gesagt, es gibt eine Ruby-Lücke, aber irgendwann kommen die Updates und wir mussten immer sagen, ja, müssen wir mal gucken, wenn es Elpine schafft, Updates zu liefern und es hat dazu geführt, dass unsere Devs zu den Containern gegangen sind und die immer eingetreten haben. Natürlich, wenn man nicht veröffentlicht, was man für offene Vulnerabilities hat, dann kann auch nichts passieren. Wir sind weggegangen von Elpine. Fedora1230, das habe ich auch probiert. Das Ergebnis war, ich konnte nicht scannen. Wissen wir also nicht. Das war der Moment, mit dem man loslegt. Das heißt, noch bevor ihr irgendwas gemacht habt, habt ihr eigentlich schon lauter Security-Probleme. Das war so ein Moment, wo wir so, what? Was ist in dieser Docker-Welt kaputt? Gucken wir uns mal einen Container an. Und zwar den Node-Container. Das ist tatsächlich der offizielle Node-Container, wenn ihr irgendwie was mit Node.js JavaScript baut und sagt, ihr macht das mit Docker und ihr nehmt den Node.js-Container als Basis, weil man ja schön die Version kriegt. Es geht damit los. Wir fangen also mit dem Base-Image an, was Build-Pack-Depth heißt. Ich habe mal geguckt, ich habe da hinterher geguckt, was das ist. Das sind eigentlich nur Zwischenlayer, wo nochmal was auf Debian Stretch installiert wird. Wo einfach noch mit App-Software dazu geworfen wird. Am Ende kommt da das ganze normale Debian-Base-Image, das wir eben schon gesehen haben und nirgendwo auf dem Weg bis hierhin werden Updates eingewählt. Das heißt, schon bevor wir überhaupt loslegen, haben wir unsere 50 Sicherheitslücken drin. Dann wird Node-NPM installiert und zwar wird das installiert, indem ein precompiled Node-NPM per CURL darunter geladen wird. Wir hatten es eben schon, CURL-Pipe nach beige, nein, so schlimm ist es nicht. Sie gucken tatsächlich, ob die Prüfe so bestimmt an der Stelle immerhin. Was wir an der Stelle natürlich nicht wissen, wie ist denn bitte das Node und das NPM kompiliert worden? Ist das OpenSSL-Stadich da reingelingt oder nicht? Wenn es ein Security-Problem in NPM gibt, welche Version ist das ganz genau, wo ist das gebaut worden, was hängt hinten dran für Libraries? Wissen wir alles nicht. Folge ist, Node-NPM können wir nicht mehr automatisch und systematisch auf Security-Probleme monitoren. Wir können also nicht irgendwie das Ding zu KRO oder zu irgendeinem anderen Thema. Wir können das monitoren. Der weiß ja nicht, dass das Node-NPM da drin steckt. Was wir machen könnten, ist, wir können uns jetzt eine handgestrickte Lösung bauen, die dieses Node-NPM nochmal irgendwie durchcheckt. Sowas mögen, ob es überhaupt nicht neue Lösungen bauen für irgendwas, weil er skaliert nicht. Ein Jamn steckt da auch noch drin. Hat einem auch jemand gesagt, dass wenn man so ein Node-Container runter lebt, da noch ein Jamn drin steckt. Hier gilt das Gleiche. Es ist eigentlich unmöglich, das systematisch auf Security-Probleme zu monitoren. Was für eine Jamn-Gasion ist da drin, bitte, in dem Container, der da läuft? Keine Ahnung. Das ist halt irgendwann gebaut worden. Gerade wenn man da noch ein latest Container den weiß man es gar nicht mehr. Das gilt so natürlich auch für alle Images, die auf diesem Base-Image aufbauen. Das heißt, dass jemand euch sagt, ich habe hier ein JavaScript-Projekt, ein Docker-Container gepackt und das gilt genau das. Und das gilt natürlich nicht nur für den Node-Container. Das gilt auch für den Ruby-Container. Ich habe mir angeguckt. Das gilt für den Python-Container. Das gilt für den PHP-Container. Das heißt, die ganzen Basiskontainer sind eigentlich alle schon mit Sicherheitslöten ausgeliefert. Hier wird die Frage gestellt nach unmöglich. Natürlich nicht unmöglich. Im Sinne von technisch unmöglich. Man kann natürlich irgendwie für all diese Container Sonderlösung stricken. Also irgendwie gucken, dass man da drin herum hantiert und es irgendwie was rausfindet und das mit irgendwas abgleicht. Das sind aber alles händische Prozesse, das muss man alles neue Software verschreiben. Mit unserem Devs haben wir uns gestritten. Die wollten nämlich gerne ein aktuelles Ruby haben, so wie sie es auch in ihrer Entwicklungsumgebung haben. Die haben auch gesagt, sie bauen sich auch den Container selbst. Sie kompellieren sich das auch selbst. Wir haben gesagt, wir wollen das systematisch checken. Wir wollen nicht irgendwelche neue Lösungen haben. Lieben Gruß an unsere lieben Entwickler, ihr seid toll. Das ist schon so ein Punkt, wo man zweifelt, ob das eigentlich der richtige Ansatz ist. Aber damit ist es nicht zu Ende. Natürlich geht das auch noch auf dem nächsten Level, Next Level Shit. Die verschiedene zusätzliche Software noch braucht. Dafür gibt es Sachen wie Docker Compose und Co. Die also jetzt anfangen, auch noch die Datenbacken aus den Docker Containern auszukommen. Auch das gucken wir uns mal an. Und zwar am Beispiel von Sentry, wer Sentry nicht kennt. Sentry ist eine Lösung, eine Plattform, wo man Stacktraces hinschicken kann von seiner Software, wenn also irgendwas schiefgegangen ist, im Betrieb. Und die sortieren kann, auswerten kann mit seinen Teams. Das gibt es auch als Selbsthost-Variante. Die bieten das als Open Source-Lösung an. Ein sogenanntes Sentry on-premise in die Hand. Und das ist ein Docker Compose Setup. Und da sind Party-Docker-Container drin. Ich habe mir das gestern tatsächlich nochmal geklont und nochmal nochmal verifiziert, was da eigentlich drin steckt. Das ist also tatsächlich das offizielle Release aus dem Master Branch von gestern. Wir haben drinnen ein Container, der heißt Tieranonexem4. Also natürlich muss Sentry irgendwie Mails schicken. Also brauche sie ein Mails-Surfer, nehmen sie sich ein Exem4. Und zwar irgend ein, den ein gewisser Tieranon gebaut hat. Wer ist Tieranon? Wissen wir nicht. Ich will ihm nichts unterstellen. Wahrscheinlich macht er einen guten Job. Aber ein Mailsurfer, den ich in meiner Infrastruktur mit Rudrechten laufen lasse, da steckt ein Mancache drin in der Version 1.5 und das ist ein Tieranon-Based mit allen Problemen, die Elbe also mitbringen. Und zwar vom 6.2.2020 also jetzt fast ein Jahr alt und damit auch seit dem Jahr nicht mit Sicherheits-Updates versorgt. Sentry benutzt Kafka-Stack für Messages intern. Das heißt wir brauchen auch noch den Kafka-Stack von Confluent. Immerhin kommt es von Confluent, die offizielle Variante. Aber auch das ist vom 22.04. Monate alt keine Security-Updates eingespielt seitdem und ich habe versucht rauszufinden wie dieser Zugkeeper-Container intern gebaut wird, es war mir nicht möglich. Da sind einen Haufen internen Container im Spiel. Da ist eine interne Bildpipeline im Spiel, da wird irgendwas mit Pip und Melk durcheinander. Ich habe nicht gesehen, ob das irgendwie komisch ist oder nicht. Aber es ist ja auch vom 22.04. Das Gleiche gilt für den Kafka vom 22.04. Dann ist das sogenannte Click-House-Surfer, der kommt von Yandex. Yandex habe ich auch noch nie gehört vom 19.05. auf ein halbes Jahr keine Sicherheits-Updates gesehen und so weiter und so fort. Obendrein kommen die Sentry-Eigene Docker-Container, das ist eine Jungle-Applikation, geht damit los, dass vom Python gebaut wird, das heißt all das, was die Python-Base-Container gesagt wurden, ist auch hier. Jeder dieser Container hat im Zweifelruhzugang zu dem, was sie da macht. Mindestens innerhalb der Container. Das heißt, dieser ganzen Liste, die jetzt hier auf dieser Folie drauf ist, all diesen Leuten, die irgendwie ihre Finger am Spiel haben, den traut ihr. Und ja, das ist die offizielle Ansage von Sentry für hier, nimmt, das ist Docker, das funktioniert. Nehmt den Container vom 2020, wo ist das Problem? Über den Chat noch gesagt, Yandex ist die russische Suchmaschine, ich hatte auch irgendwie gesehen, dass es irgendwie Richtung Russland zeigt, hat es mir näher angeguckt. Gut, kann man auch immer legen, vertraut man den, vertraut man den nicht. Problem ist trotzdem alt, auch wenn er den vertraut. So, was haben wir außerdem, wenn wir über Docker reden, das war jetzt quasi nur die Security-Seite aus den Base-Images, da ist überhaupt noch nichts passiert. Außerdem haben wir wildeste Shell-Script-Schlachten, da, der sich mal angeguckt hat, wie so ein Docker-Container gebaut wird, fragt sich, ob wir tatsächlich wieder 1995 angekommen sind. Ruby-Base-Image benutzt mit Weget irgendwas mit einer Schad 256 Summe vergleichen, die irgendwie hart da reingekotet ist, schickt das Ganze in GCC, räumt natürlich den GCC auch wieder weg, weil sonst machen wir einen neuen Leer auf und so weiter und so fort. PHP ähnlich, auch da machen wir mit GCC und dann nochmal ein GPG-Check von irgendwelchen Schlüsselservern, alles in einem Einz-Heiler mit irgendwie Doppel-Uns und umgebrochen, um dann nochmal ein Ficker und Mac aufzurufen. Im Kern all diese SED und AVK-Disaster, die wir eigentlich mit Enzybil und Saltstack so schön im Griff hatten. Dafür hatten wir eigentlich so schön Automatisierungssoftware geschrieben, jetzt sind wir wieder ganz am Anfang und machen wieder Shell-Script-Schlachten. So was sieht man da auch relativ häufig, da läuft ja nichts anderes, was soll das Problem sein? PHP-Base-Image macht das zum Beispiel nochmal eben auf www.html mal mal change mal 777 natürlich läuft das in einer echten Umgebung, natürlich ist das eine Linux-Umgebung, die ihr habt und wenn ihr einen Angriff darauf habt und jemand irgendwie in eurer Anwendung eine Lücke gelassen hat und Schreibrechte hat, dann schreibt ihr euch dann natürlich irgendwie Sachen weg und überschreibt euch die Anwendung genauso wie das in jedem normalen Linux und in einem anderen Environment auch gilt. Sachen als gut laufen lassen, haben wir auch relativ häufig gesehen wo ist das Problem, haben Software doch schon immer als gut laufen lassen, ist ja im Docker-Container wo ist das Problem. Dann gibt es da lauter crude Wrapper-Script um irgendwie diese Env-Variabeln die da von außen rein kommen in Confix zu übersetzen die sind meistens noch viel wilder als die Shell-Script-Schlachten, die den Container bauen. Es gibt ein Haufen Annahmen über irgendwelche intern Continuous Integration Continuous Delivered-Systeme diverse Container sind überhaupt nicht nachbaubar überprüfbar zum Beispiel von Su-Keeper und Kafka hatte ich das Problem dass ich tatsächlich nicht mehr sagen konnte, wo das herkommt weil irgendwas internes von Conflienter mitläuft und irgendwas baut, keine Ahnung wo das herkommt muss man halt vertrauen und dazu die ganzen neuen Halbs, die aus der Docker-Welt kommen also die ganzen Probleme die auftreten, weil Docker eben doch nicht so trivial ist wie sie tun und die neuen Lösungen die dann eben mal ganz einfach um die Ecke kommen ich habe so viele neue HTTP-Proxies in den letzten 1, 2 Jahren gesehen, die alle meinten ist noch alles kein Problem HA-Proxy 20 Jahre Entwicklung so ein dickes Stück Software aber wir schreiben mal eben in 2 Jahren proxy neu alles kein Problem so und jetzt die schlechte Nachricht ja tatsächlich, es gibt eine schlechte Nachricht dabei die Beispiele die ich euch gezeigt habe sind nicht die Ausnahme ich hätte ja euch gern einfach nur die Disarfe gezeigt aber es ist tatsächlich so, dass diese Docker-Welter draußen genauso aussieht und auch das Läste stimmt genauso wie ich es dahingeschrieben habe ich hatte tatsächlich im letzten Jahr kein Docker-Container kein Setup in der Hand wo ich nicht auf den ersten Blick gesagt habe das stinkt doch hier, hier ist doch irgendwie Sicherheitslücken drin hier passiert doch irgendwas da können wir nicht mehr feststellen ob wir dem Ding eigentlich trauen oder nicht mehr trauen denn das was wir hier gesehen haben mit Zenfie ist wirklich nicht schlechter als der Rest der Welt die machen eben das was man im Docker-Universum gerade tut das was wir hier gesehen haben ist dann der Ding wenn wir über Docker reden lassen wir mal den Chat ein bisschen rankommen während wir diesen Darm hier zu gucken während sie über Docker nachdenken was tun, wenn wir das sehen, wenn wir irgendwie sehen dass diese Docker-Welt tatsächlich da draußen so ganz am Anfang steht und noch viele Jahre wahrscheinlich braucht und wirklich brauchbar stabil zu werden das erste ist wenn hier irgendwo ein Docker-Container in die Hand gebrückt bekommen von irgendjemandem und es drückt euch gerade wirklich jeder ein Docker-Container in die Hand schaut euch die Docker-Files an die sind meistens irgendwo zu finden wenn ihr beim Docker-Hub guckt ist ganz oft einfach direkt der Link in das Docker-File zugetappt guckt es euch an was wir jetzt tun werdet wir haben das tatsächlich jedes mal geteilt wenn wir die Docker-Files geguckt haben wahrscheinlich wollte der lieber einen in Container bauen tatsächlich ist es bei uns die Ansage wenn wir was in Docker ausrollen wollen dann bauen wir unsere Container selber weil das was da draußen um die Ecke geworfen wird wird es echt gruselig anecken wenn ihr anfangen Container selbst zu bauen nutzt vertrauenswürdige und minimale Base-Images also wirklich tatsächlich irgendwie dieses wo noch nichts passiert ist wo noch niemand irgendwie am Anfang mal irgendwas mit GCC reinkompalliert hat oder irgendwo noch was reinkupiert hat und wahrscheinlich werdet ihr im ersten Schritt erstmal die Base-Images updaten müsstet das heißt tatsächlich ist es bei uns so wie wir setzen inzwischen auf Ubuntu auf unser Docker-Bild-Prozess macht im ersten Schritt erstmal ein Update dann wären die Container zwar größer aber sie sind immerhin nicht mehr voller Sicherheitslücken dann nutzt die Pakete die ihr mit dem Paketmanager bekommt das ist was auch da streiten wir uns immer wieder mit unseren Devs rum weil natürlich wollen die gerne den Neues in heißen Scheiß und dann kommen die Ops um die Ecke und sagen ne, ihr nehmt bitte das Ruby oder das Python was ihr aus dem Paketmanager bekommt und ja, das ist nicht das Neueste sondern das ist das zweite Release zurück baut nicht selbst heißt im Folge, ihr könnt im Zweifel nicht die neuesten Version benutzen warum das Ganze, wenn ihr den Paketmanager benutzt dann könnt ihr sie wenigstens systematisch checken ob Security Probleme gibt auch wenn euch eure Devs dafür hassen und sie werden euch dafür hassen nochmal einen lieben Gruß an unsere Devs ich liebe euch alle im Kern stellt dieselben Security-Anforderungen wie an jeden anderen Linux-Sover auch natürlich warum denn nicht natürlich läuft dieses Software süß von außen erreichbar und da drin läuft ein Linux und natürlich gelten alle Erkenntnisse die wir haben aus der Security Perspektive natürlich auch für die Docker-Container und A und O in Security ist, wir brauchen Patches wir müssen alles so schnell wie möglich patchen wenn ihr die Container habt scannen sie systematisch und vor allem auch kontinuierlich auf Security Problem es reicht nicht in dem Moment zu scannen wenn ihr das ganze Ding baut und zu sagen, ja wir haben ja keine Lücken drin sondern ihr müsst es eigentlich jeden Tag machen wir machen es ist tatsächlich wir haben eben diesen Security Scanner wo wir Geld dafür bezahlen dann gibt es auch einen Open Source und da haben wir tatsächlich auch Monitoring drauf das heißt wir haben rote Lampen die gehen an wenn unsere Security Scanner sagt da ist eine neue Lücke drin und da müssen wir die Container eben neu bauen und wenn ihr Container bereitstellt für andere heißt es auch, ihr seid in der Pflicht kontinuierlich neue Images zu veröffentlichen wenn es Security Probleme in den Base-Images gibt ihr könnt also nicht hingehen können sagen ich habe heute eine neue Version von meinem Programm gemacht von meiner Web App gemacht von meinem Jungle in der Jungle App ist alles gut das ist der Release Docker Container raus und mit dem nächsten Release gibt es den nächsten Docker Container so weit mal kurz zurück springen so weit die bittere Wahrheit über Docker 2020 was hatten wir noch so jetzt mal eine kleine Rundschau von Sachen die uns einfach über den Weg gelaufen sind die nirgendwo reingepasst haben Anaconda behauptet man kann es ohne Route Access installieren was man dazu machen muss mit Zulu eingeben das fand ich wirklich gut man kann auch in Python-C-Style programmieren ein schönes Stück Code aus SendV genommen wo sie versuchen, interne Netzwerkadapter zu finden es ist ja nicht so, dass man in Python Bibliotheken für sowas hat wo man sagen kann, gib mir doch mal bitte unsere Netzwerkinterfaces nein, nein man kann tatsächlich direkt auf irgendwelche Stockades gehen und dann mit irgendwelchen Binearmasken auch in Python Sachen darunter lutschen Indian Standard Time wir haben mit Zeitzonen relativ viel zu tun gehabt liegt vor allem dass wir mit Leuten zusammenarbeiten die rund um die Welt verteilt sind und im letzten Jahr tatsächlich auch mit Leuten in Indian sitzen hat jemand eine Idee was das Problem ist neben der Zeitzonen gehört, dass der Stream weg war nochmal den letzten Satz ich wollte euch nochmal fragen ob ihr wisst was das Problem mit Indians Standard Time ist ihr seid alle noch bei Docker was ihr seid jetzt alle total verschreckt wir treffen uns hinterher nochmal im JITZ ihr macht eine Therapiesession UTC 5 Stunden 30 es gibt tatsächlich Zeitzonen die nicht die nicht auf ganze Stunden geteilt sind auch das gibt es, damit muss man umgehen können macht es total da ist die Antwort 30 Minuten oft jetzt genauer Solstack hat dieses Jahr ein paar wirklich große Böcker geschossen wir hatten Remote Code Execution im Saltmaster das heißt wenn der Saltmaster seine Ports im Internet hatte konnte man beliebige Befehle mit Route auf allen Saltmanions ausführen und das obwohl eigentlich überall steht, dass die Kommunikation mit dem Saltmaster per Zatfikat abgesichert ist die Lücke haben sie veröffentlicht am 1. Mai das macht es besonders schön da sind nämlich alle Obst nicht arbeiten danach war Wochenende das heißt wir hatten mal eben 3-4 Tage nach den 3-4 Tagen nach der Veröffentlichung bis die Obst wirklich wieder am Tisch saßen waren in dieser Welt auch schon mehrere Tausend Rechenzentren abgeschossen worden, das ging halt wirklich schnell dass die da die Angriff lieben nebenbei hat Saltstack auch noch ganz unangekündigt keine Patches für ältere Versionen mehr ausgeliefert das heißt ganz plötzlich waren alte Versionen die lange supportet waren, nicht mehr supportet hat großen Spaß gemacht da sind wirklich ganze Rechenzentren am Stück übernommen worden und weil das so gut gelaufen ist hatte im Herbst Saltstack noch mal eine Remote Code execution im Saltmaster oh ich lerne gerade das Nepal auch eine schräge Zeit hat 5 Stunden und 45 Minuten, wieder was sie lernt und Enzymbil mal wieder ist dieses Jahr relativ oft gefallen und hat es auch schon immer wieder immer wieder schöne Dinge das ist das was uns dieses Jahr begegnet ist Enzymbil möchte bitte wenn man eine Loop macht und eine Liste haben und wenn man ihnen eine Liste gibt für den Enzybil das Doof was auch immer wieder schön ist hatten wir jetzt schon ein paar Mal immer wieder wenn man Enzymbil einem Generator gibt wo eine Liste rauskommt, ist ja immer in Python dann serialisiert der Generator Enzymbil den Generator in den Industrinkrepräsentationen und macht daraus eine Liste von Buchstaben großes Kino so das war das sonstige Fazit gilt wie jedes Jahr alles schlimm, ich gehe Kreuz züchten auf der Webseite schreibt mir wenn ihr was habt, wenn euch was begegnet im nächsten Jahr wenn ich genug kriege, gucken wir mal wie wir nächstes Jahr, ob wir nächstes Jahr Dev Ops die Sasser NT machen oder so was auf der Seite ist auch ein Jitzi-Raum verlinkt der auf der Map ist und zwar gibt es eine Sushi-Bar kommt auch da gern hin, hier findet mich da, ich bin der mit den geregelten Strumpfhosen jetzt kriege ich natürlich das Bild nicht rein das habe ich so ein schönes Bild gemacht wir findet es schon, direkt an der Laune einfach durch das Katzentor gehen, links in die Straße, das erste Haus können wir uns gleich mal an der Bar treffen können wir weiter quatschen genau auf der Foxy Sasser NT auch der direkt Link in das Jitzi rein das ist ja jetzt nicht auf der 2D-Map-Seit und jetzt haben wir noch ein paar Minuten gern für Rückfragen falls jemand darauf vorbereitet ist Rückfragen an mich zu stellen also erstmal vielen Dank für deinen spannenden Vortrag und ich würde sagen die meist gefragte Frage wäre erstmal ob du nochmal kurz sagen kannst welches scanner ihr denn benutzt welches so gibt also es gibt von Redhead ein Open Source Projekt dessen Name mir blöderweise gerade entfallen ist das kann ich so ein bisschen Produktwerbung machen was ich will es eigentlich gar nicht tun wir benutzen KRO das schreibt sich ein bisschen komisch mit Q am Anfang ist von Redhead das ist ein Docker Registry die machen auch manchmal komische Sachen läuft nicht ganz rund, wir haben manchmal so das Gefühl ihr habt einen Job und das ist Sachen zu scannen kriegen wir Scans die haben eine API kann man schön eigene Tests ranhängen wir haben auch irgendwo so ein Sensor BlackIn veröffentlicht was das tatsächlich tut gegen diese API zu checken gerne mich anschreiben wenn ihr da mehr haben wollt ihr habt die Kontaktdaten hier im Chat hat es jemand richtig geschrieben gerade es gibt das eben auch als Open Source das ganze Ding haben wir uns aber nie angeguckt dann haben wir als nächstes so zu sagen ein bisschen die Relativierung wie relevant sind Sicherheitslücken wirklich Docker Containerwerten in der Cloud verwendet Remote Code Execution Notwendig Fragezeichen genau wie relevant sind die, die sind natürlich genauso relevant wie wenn ihr sie auf eurem Linux oder eurem Linux-Sofa laufen habt es heißt ja nicht dass man gleich aus dem Docker Container ausbrechen muss um irgendwie auf die Cloud-Kisten runterzukommen sondern ihr habt eine Anwendung eine Web-Anwendung ich spreche am besten ein einfachsten Fall mit der Datenbank hinten dran, das sind personenbezogene Daten dran das heißt wenn ich das irgendwie schaffe in die Anwendung einzubrechen dann kann ich anfangen darum zu springen und ich habe da ein Liedungsenvironment und wenn meine Anwendung als Ruht läuft und meine Anwendung irgendwie mit Change Mode 777 Schreibrechte hat dann kann ich natürlich in allen Angriffsvektoren darauf fahren auf die App kann ausbrechen aus meinen Verzeichnissen kann irgendwie Sachen hinschreiben kann anfangen meinen PRP Interpreter zu verwirren und mir der Backdoor aufmachen und das reicht ja schon wenn der Backdoor in den Container reingeht weil dann kann ich eben hingehen und kann mich weiter durchhangen und kann dann in die personenbezogene Daten sonst was rausziehen das heißt euer Container ist man muss ein bisschen aufpassen ist dann natürlich ein Linux drin was ich angreifen kann dann gibt es nochmal die Frage warum Ubuntu als Base Image warum Ubuntu als Base Image das war das Ergebnis dieses Tests wir haben halt tatsächlich ganz viele Base Images genommen und haben sie mal in den Container hoch in den Scanner hochgeladen im Chat kommt auch gerade die Antwort wie die Open Source Variante davon heißt die heißt Claire, Dankeschön für den Input und haben diese Images hochgeladen, haben geguckt was ist eigentlich jetzt hier in der Basis und es war halt eben alles schlimm tatsächlich es war irgendwie alles voller Lücken und dann haben wir geguckt was können wir denn dagegen tun und Ubuntu war das Image wo man zumindest wenn man das Base Image initial updated also in dem Moment wo man das Baud Updates einspielt man auf den besten Stand rausgekommen ist das heißt da waren die meisten Lücken zu und genau es waren immer noch Sachen wo keine Patches da waren das ist aber dann die gleiche Situation wie wir auf dem Debin oder Ubuntu Server auch haben wenn du keine Patches bereitstellt ist man irgendwie im Dreck oder muss halt selber patchen das heißt wir haben gesagt wenn wir ein Ubuntu Image nehmen können wir immerhin mit Docker auf den Stand dem wir auch mit einem Ubuntu Server da draußen haben und der war besser als Debin tatsächlich die Update versuchen wir besser als bei Debin deswegen ok ein paar wenige Fragen sind noch übrig aber unsere Zeit ist eigentlich zu Ende deswegen schicke ich euch jetzt alle in