Ziel ist es, das Ganze einfach mal so in die Breite zu gehen, was es denn so im Bereich Container Security an Optionen gibt. Da haben ich vermutlich hier die wenigsten kennen. Noch ein paar Worte zu mir. Mein Name ist Holger Ganticow. Ich habe an der einzigen Hochschule mit zwei Wintersemestern namentlich FUTWANG Informatik studiert

und bin so über Praktikum, Diplomarbeit bei meinem jetzigen Brötchengeber S&C gelandet. Und seit inzwischen ja knapp über acht Jahren als Senior Assistance Engineer im CRI Berechnungsbereich beim Automotive Kunden unterwegs. Und ja, so in meiner Freizeit forsche ich dann an meiner alten Hochschule am Institut für Cloud Computing und IT Sicherheit

in Kooperation mit der Plymouth University. Und da ist so mein Steckenpferdchen HPC mit Vertraulichkeitsanforderungen in der Cloud. Und ja, wie gesagt, mein Brötchengeber ist S&C bzw. der Teil von Atos, der früher vom Rebrand irgendwie mal als S&C oder kurz oder lang Science & Computing bekannt war

und bei dem sich gut 300 Mann und Frau in Tübingen, München, Berlin, Düsseldorf, Ingolstadt mit IT-Dienstleistungen, Software für technisch-wissenschaftliche Berechnungsumgebungen auseinandersetzen und damit Kunden aus ganz Deutschland und weltweit irgendwie bedienen. Wie man unschwer erkennen kann, wir haben so einen gewissen Fokus auf dem Automotive Sektor.

Falls zufällig noch wer auf Jobsuche sein sollte, darf er sich gern bei mir melden, dann würde ich entsprechend in Kontakt herstellen. Also wir sind händeringend am Leute suchen, wie ich gehört habe. Ja, ansonsten genug des Werbeblocks, gehen wir mal aufs eigentliche Programm. Was habe ich mitgebracht? So als Aufhänger habe ich mal so ein paar Zitate aus dem Containerumfeld und zur Security mitgebracht.

Dann wollen wir mal schauen, wo denn eigentlich so der schlechte Ruf letztendlich herkommt und dann anschauen, was sich so seit 2015 getan hat. Also einen Vortrag wollte ich eigentlich letztes Jahr schon halten, bin ich leider krank aus dem Urlaub zurückgekommen. Insofern, sorry, falls letztes Jahr wer da gewesen sein sollte.

Ja, ansonsten was sonst noch in der letzten Zeit so passiert und unter dem Aspekt trotzdem, was man einfach noch im Hinterkopf behalten sollte, trotz all der Möglichkeiten, die man da irgendwie einsetzen kann und hinterher noch Zusammenfassung und Fazit. Ja, Informatiker fangen ganz gern bei Null an, deswegen hier auch nochmal so ein bisschen Einleitung vorweg. Da ich vor zwei Jahren irgendwie was zu Container und HPC erzählt habe,

nochmal so der Hinweis, HPC ist eher dieses Mal nicht. Also nichts mit Singularity und Shifter. Docker Alternativen kommen auch nur kurz am Rande auf. Also LXC und Rocker ist eher draußen an der Stelle. Und ja, Orchestrierung musste ich mich auch ein bisschen mit zurückhalten. Gab es da vorhin auch schon einen Talk und direkt im Anschluss nochmal einen.

Insofern, wen den interessiert, gibt es genug Alternativprogramm. Ansonsten nochmal ein kurzes Container-Intro. Wenn man sich das mal so anschaut, wie sich das denn so die letzten Jahre oder generell irgendwie entwickelt hat, so konzeptionell. Man möchte irgendwie was isolieren und irgendwie im Prozess sieht man nicht das ganze Fallsystem.

Haben wir CHRoot unter BSD. Später dann ein bisschen aufgebohrt, die Jails. Unter Linux sind dann 2002 die Namespaces dazugekommen. 2006 dann erweitert. Irgendwann kamen dann mal OpenVZ und vServer. Ja, Solaris und Konsorten gibt es dann auch noch. Da hat man die Zones, also auch ein schönes Mittel für Betriebssystem, oder für Virtualisierung auf Betriebssystem-Ebene.

Und ja, die Z-Groups, also als zweiter Eckpfeiler, neben den Namespaces, ist dann auch 2006 irgendwie um die Ecke gekommen. Also man sieht Namespaces und Z-Groups so als Pfeiler von Containervirtualisierung unter Linux. Gibt es schon relativ lang. Darauf aufbauen kam dann 2006, 2008 LXC um die Ecke.

Ja, bis dann Docker kam. War dann auch schon 2013 und noch dann drauf 2015 ein Rocket. Ja, insofern, man sieht so die Grundlagen dahinter sind jetzt eigentlich nicht grundsätzlich neu an der Stelle. Was Container so im Vergleich zu Hypervisor-basierter Virtualisierung ausmacht, ist das.

Also ja, gemeinsam das Ziel, ich möchte irgendwie meine Hardware effizient nutzen. Und wenn ich Hypervisor-basiert habe und ich möchte halt, es geht mir darum diese Applikation hier auszuliefern, dann habe ich halt hier mein komplettes Betriebssystem noch irgendwie im Stack mit drin. Während hingegen ich beim Containerisierten halt einfach quasi die Applikation und ihre Abhängigkeit nur ausliefern muss.

Das heißt, ich habe ein deutlich kleineres Paket, was ich weitergeben muss. Nachteil ist, ich bin aufs Betriebssystem limitiert. Einfach vor dem Hintergrund, dass sich alle Container den laufenden Hostkernel irgendwie teilen. Aber in der Linux-Welt sollte das jetzt denke ich mal nicht unbedingt das Problem sein. Ansonsten eine kurze Docker-Intro.

Ja, Docker All the Things ist nach wie vor nur so ein bisschen das Hype-Thema. Und ja, vor einiger Zeit hatten sie noch das Statement auf der Homepage, dass sie eine offene Plattform für Entwickler, Sysadmins, Build, Chip und Run und so weiter, verteilt Applikationen, Microservices, alles schön und gut. So vom Laptop, Data Center, VM oder in der Cloud. Also es ist völlig egal, wo das laufen soll.

Wir haben quasi ein Paket. Und ja, inzwischen haben sie so diese etwas technischere Definition irgendwie zusammengefasst und das Marketing hat übernommen und inzwischen sind sie der Meinung, sie sind hier die world leading Software-Container-Plattform. Also schon so ein gesundes Selbstverständnis und vor allem nicht einfach nur eine Runtime, sondern halt eine komplette Plattform.

Und wenn man sich das mal so anschaut, was irgendwie alles gedockert, branded ist, im Prinzip, ja, sie setzen da doch relativ stark irgendwie ihr Claim und haben auch so einen gewissen Allmachtanspruch. Insofern vor dem Hintergrund haben auch diverse Leute irgendwie so ein bisschen sorgen, dass sie das neue, alte Microsoft werden.

Wir erinnern uns irgendwie zurück. Windows und Internet Explorer und so was. Bündelung mit einem Betriebssystem. Docker hat ja dann irgendwann mal angefangen, quasi Swarm mit auszuliefern, also als Orchestrierungswerkzeug. Und ja, da wird es dann halt einfach irgendwann mal argumentativ schwierig zu sagen, warum will ich Kubernetes oder Mesos oder irgendwas, wenn da ja schon was mitkommt.

Und ja, bei der Betriebssystemwelt oder Browserwelt war es ja dann jetzt endlich ähnlich. Also inzwischen sind sie momentan dran. Diverse Komponenten, diese als Plumbing bezeichnen, beispielsweise irgendwie Run-C oder Container-Deal-Network und Co. Einfach quasi standalone irgendwie freizugeben, das Ganze modularer zu machen,

sodass man das auch in anderen Projekten irgendwie einsetzen kann. Dann haben sie ja doch den Ansatz mit dem Projekt Mobi. Also insofern vor dem Hintergrund hoffen wir mal, dass uns ein zweites Microsoft in der Stelle letztendlich erspart bleibt. Ja, insofern Docker, Docker, Docker. Ja, nochmal ein ganz kurzes Docker 101.

Was ist Docker? Vereinfacht gesagt eine Anwendung für Linux, also mal den Plattformgedanken außen vor, um Anwendungen voneinander zu isolieren. Das Mittel zum Zweck ist hier einfach die Betriebssystemvirtualisierung und soll einfach die Bereitstellung, den Transport und die Isolierung der genutzten Ressourcen vereinfachen alles vor dem Hintergrund, dass ich irgendwie Prozesse in Container A laufen habe,

die nicht auf Prozesse in Container B zugreifen können und so weiter. Und so die eingesetzten Technologien sind Z-Groups und Namespaces, ja, so im tiefsten Inneren sozusagen. Also früher waren sie auch mal auf der LXC-Schnittstelle unterwegs. Inzwischen nutzen sie eine eigene lib-Container. Also ein paar ganz kurze Terminologien und Kernkomponenten.

Was brauchen wir? Die kommen später mal vor. Punkt eins, wir haben unseren Docker-Demon. Ne, wir haben unseren, fangen wir mal beim Docker Host an. Das ist mein Linux-System, vorzugsweise auf dem der Docker-Demon läuft. Das ist die Engine. Und mit dem sind halt die Kleins am Interagieren. Und ja, und so werden dann halt Container gestartet.

Container ist im Prinzip ein gestattetes Image. Das Image beinhaltet die Applikation und so das Environment, alles, was die Applikation zum Laufen braucht. Und der Container ist halt das, was ich starte, stoppe und so weiter, diese ganzen Life-Cycle-Operationen draufmache. Die Images bekomme ich in der Regel aus einer Registry, also quasi so im App Store für Images.

Gibt es Public, Private und so weiter. Und wenn ich mir selber Images bauen will, dann nutze ich den Docker-File dazu. Inzwischen auch so vor dem Hintergrund, das Ganze modularer zu machen und aufzudröseln, sieht die Architektur jetzt ein bisschen anders aus. Genau, wir haben inzwischen nur noch, oder wir haben inzwischen die Docker-Engine, an denen die bisherigen Tools dann alle andocken können.

Für die ändert sich nichts. Im Hintergrund läuft das Ganze dann irgendwie so weiter, dass die Docker-Engine den Container, die triggert und sagt, hier, lag mal ein Image runter und starte das mal. Und dieses Starten wird dann halt eben von Run-C durchgeführt.

Ja, Vorteil ist, ich kann diese Komponenten im Zweifelsfall ersetzen. Also ich kann an dieser Stelle theoretisch auch eine andere, ja, Container-Runtime, die zum OCI-Standard irgendwie konform ist, irgendwie da andocken und das Ganze einfach so ein bisschen, ja, abwechslungsreicher oder einfach, ja, flexibler gestalten.

Wesentlicher Punkt, auf den man einfach nochmal eingehen soll, das hatte ich vorhin schon gesagt, es ist nicht grundsätzlich Neues. Ja, das Ganze basiert einfach auf bestehenden Kernel-Technologien. Jerome Patersoni, einer der Docker-Chefentwickler, hatte da mal so in der Präsentation quasi diesen Beweis drin,

hat einfach mal die Kernel-Quellen durchsucht und mal ein bisschen rumgesucht, mal nach LXC, keine Ergebnisse gefunden. Ja, gut, wenn man nach Container sucht, findet man diverse andere Ergebnisse, die aber mit den Containern, um die es hier geht, relativ wenig zu tun hat. Da geht es einfach um interne Datenstrukturen und dergleichen. Insofern, also im Vergleich zu anderen Betriebssystemen wie Solaris

ist ja die Container-Technologie bei Linux jetzt nicht so tief im Betriebssystem verankert. Im Prinzip ist es ein schöneres Wort für die Kombination aus Namespaces und Z-Groups, also Namespaces zur Bereitstellung der Illusionen von isoliertem Betrieb

und die Z-Groups einfach, um den Ressourcenverbrauch von einzelnen Prozessen zu limitieren. Also spricht das ein Prozess, der irgendwie gerade amok läuft, nicht das ganze Rostsystem irgendwie gegen die Wand fahren kann. Ja, momentan ist so der Status bei Namespaces ja irgendwie hinreichend, was es gibt. Es ist nicht alles irgendwie Namespace.

Zum Beispiel wird man sich noch irgendwie wünschen, dass es noch irgendwie ein Timenamespace gibt, damit in den Containern eine andere Zeit als auf dem Rost laufen kann. Aber es ist momentan so ein Status, dass es hinreichend ist. Ja, ansonsten was kann Docker für dich tun? Ganz kurz, so Sachen wie Abhängigkeiten isolieren. Gerade in dem Umfeld, wo ich unterwegs bin, kommt es durchaus mal vor,

dass ich irgendwie auf einem Cluster mal irgendwie zwei Dutzend Versionen der gleichen Applikation installiert werden soll. Da rennt man dann immer mal wieder in so Abhängigkeitsfallen irgendwie rein. Ja, für die Version brauche ich die Library, für die andere Version brauche ich die andere Library. Und man steht halt da und muss gucken, wie man das Ganze irgendwie ins Laufen bekommt.

Oder ausliefern von legacy-Code auf einem modernen Betriebssystem. Da eignet sich das auch großartig dazu. Ansonsten ja eben die ganze Dependency-Geschichte und Mittel zum einfachen Code auszuliefern. Ansonsten Workflow, wenn es mit darum geht, dass ich irgendwie einen komplexen Workflow habe,

der jetzt nicht einfach nur aus einer Applikation besteht, sondern ich habe irgendwie, keine Ahnung, zum Beispiel irgendwie Genetic oder Genomic Sequencing Code mit allen möglichen Abhängigkeiten auf irgendwie Python, auf sonst irgendwas, was mir dann irgendwie beim Betriebssystem-Update um die Ohren fliegt. Dafür ist das ganz, ganz groß.

Dazu der Punkt der Reproduzierbarkeit. Ich kann meinen Container oder mein Image auch irgendwie später noch mal irgendwie aus dem Schrank ziehen und habe genau das Environment, mit dem ich das genutzt habe. Ja, das ist eine relativ nette Sache. Und gerade so im Bereich des Scientific Computing und überall, wo irgendwie gerechnet wird, ist das irgendwie ganz nett. Das ist ein Beispiel von ein paar Tübingern, die machen Genomic Sequencing

und die hatten eben das Problem, dass sie so eine sehr, sehr komplexe und fragile Pipeline hatten, die ihnen irgendwie mehrfach um die Ohren geflogen ist, wenn sie auch nur irgendwie schief geguckt haben. Und die haben sich dann letztendlich dafür entschieden, das zu kontenerisieren und sind sehr, sehr gut bis jetzt damit gefahren. Und ja, überall, wo es irgendwie um Reproduzierbarkeit geht,

ist so eine Lösung halt einfach schick. Ansonsten Performance nah am Blech. Es gibt dieses wunderbare IBM Docker Paper, was das irgendwie mal so in allen Lebenslagen irgendwie durchgemessen hat. Und zum Fazit kam da so im Vergleich zu KVM, die Performance eigentlich in allen Lebenslagen besser ist, was auch irgendwie naheliegend ist.

Aber ansonsten, ja, generell der Performance-Overhead im Vergleich zu Bare Metal sehr gering ist und man einfach abwiegen muss, ob dann die Vorteile nicht überwiegen. Ansonsten, was im Alltag vielleicht eher interessant ist, das ist jetzt mal ein Container, der einfach mal ein schlichtes Hello World ausgibt. Also der war dann irgendwie in einer halben Sekunde irgendwie durchgelaufen.

Wenn ich sowas mit einer virtuellen Maschine machen möchte, einfach die ganze Start-up-Zeit ist einfach wesentlich länger und macht das Ganze halt auch für Microservices UKO irgendwie interessant, dass ich quasi pro Anfrage irgendwie was starte und dergleichen. Auf jeden Fall eine nette Lösung, aber behalte mal irgendwie bei. Aber Container sind keine magischen virtuellen Maschinen,

sondern ein bisschen was anderes. Ja, genug der Einleitung. Containers do not contain. Ein schönes Zitat von Herrn Welch, der irgendwie SC Linux-Entwickler ist bei Red Hat und sich da auch irgendwie so um die Containerintegration irgendwie kümmern sollte. Und ja, es ist einfach so, dass ein ganz großer Hemmschuh

beim Einsatz von Containern einfach das Security-Thema ist, weil es häufig einfach irgendwie vor dem Hintergrund von solchen Aussprüchen so eine gewisse geistige Blockade irgendwie verursacht. Klar, wie bei allen Gerüchten ist meistens irgendwie so ein wahrer Kern dran, aber schauen wir uns mal an, was denn so an Meinungen in dem Umfeld irgendwie kursiert. Eben von Herrn Welch gibt es auch noch das nette Zitat,

wo er quasi kritisiert, dass doch diverse Leute der Meinung sind, dass Stalker so der Heilsbringer ist, dass es einfach sämtliche Nachteile, die irgendwie Virtualisierung mit sich bringt, einfach ad absurdum führt, weghaut und alles schöner, schneller, besser ist und so weiter. Und es einfach auch vor dem Hintergrund von vielen Leuten

so als 1 zu 1 Ersatz für virtuelle Maschinen eingesetzt wird. Und das sollte man eigentlich nach Möglichkeit nicht unbedingt tun. Das kritisiert er hier. Ansonsten musste auch Jerome Patersoni zugeben, also einer der Chefentwickler irgendwie bei Docker, dass zumindest in der Anfangszeit die Sicherheit da irgendwie nicht so ganz optimal war,

aber es ist ja doch etwas irgendwie Manpower reinstecken wollen, das irgendwie letztendlich besser machen zu wollen. Und von Theo de Raat gibt es noch dieses schöne Zitat, wo er irgendwie ja noch mal freundlich darauf hinweist, formulieren wir es mal so, dass es eigentlich keine Software ohne Sicherheitslücken geben kann und Virtualisierung ist ein Aspekt davon.

Das Schöne war, so am Anfang, als das Zitat rauskam, konnte man noch sagen, irgendwie er war wenigstens Konsequenz, es gibt kein OpenBSD-Hypervisor. Inzwischen hat er sich das ja anders überlegt. Insofern schauen wir mal, was da rauskommt. Ich habe nicht so unglaublich viel davon gehört. Also insofern fassen wir zusammen, wie mit jeder Software sind auch Virtualisierungsschichten in jeglicher Weise irgendwie von Sicherheitslücken geplant.

Schauen wir uns mal an, was letztes Jahr mit VMWare um Jahreswechsel war und irgendwie neulich mit Xen. Also insofern ist im Zweifelsfall ein Risiko, mit dem man leben muss. Ansonsten zum Abschluss noch von Jerome, dieses schöne Zitat,

der Security Status best described as it's complicated. Aber wenn man sich das jetzt mal genau anschaut, und das hat Ian Jackson bzw. ein Kollege von ihm für die Fostim 2015 gemacht, der hat einfach mal so ein bisschen Erbsenzählerei gemacht. Der Vortrag war unter dem etwas irritierenden Titel Surviving the Zombie Epikalypse. Ich saß eigentlich nur zufällig drin und fand den Titel irgendwie lustig.

Und die haben sich mal die Mühe gemacht, die einzelnen CVEs oder die Anzahl der CVEs, die einzelnen Lösungen gegenüberzustellen. Man sollte noch Fairness halber darauf hinweisen, dass Ian Jackson bei Cytrix arbeitet, Cytrix und Xen. Insofern vielleicht hat er sich mal verzählt.

Aber ansonsten, ich gehe nach dem Jahr irgendwie nicht mehr so ganz davon aus, dass irgendwie Xen nochmal auf die besonders guten Zahlen, wie da kam. Also wenn man Fefe irgendwie glauben mag, ist irgendwie Xens neue Flash. Insofern schauen wir mal, eigentlich sieht das relativ gut aus, dass jetzt irgendwie hier Xen para-virtualisiert am sichersten ist.

Und nehmen wir jetzt einfach mal an, dass das stimmt, glaube ich ihm an der Stelle. Also er hatte die Kategorien, einmal hier Privilege Escalation, also dass ich aus dem Guest, also aus meinem Virtualisierungsgast raus auf das Hostsystem ausbrechen kann, dass ich aus meinem Gast raus den Nile of Service fahren kann, das ist die Kategorie. Und dann das beliebte Information Leakage,

dass ich irgendwie über die anderen VMs oder über den Host irgendwelche Informationen kriege, die ich sonst eigentlich nicht bekommen sollte. Also merken wir uns mal, sieht soweit ganz gut aus. Kombi KVM QEMO sieht dann schon nicht mehr ganz so gut aus. Was aber eigentlich meiner Meinung nach relativ spannend ist, ist nach wie vor eigentlich eine ziemlich beliebte Lösung,

was Virtualisierung unter Linux angeht. Und wenn man dann mal hier die Linux App Container dagegen setzt, so hat er das quasi genannt. Ziel ist es einfach diese App Container, nicht ein eins zu eins Ersatz für virtuelle Maschinen, wo sich ein User beliebig auszummeln kann, sondern ich habe eine Applikation drin laufen,

die macht irgendwas, sie läuft unter einer anderen User ID als Route. Dann sieht das Ganze so im Vergleich zu KVM und QEMO schon mal nicht mehr ganz so schlecht aus. Sogar relativ eben würde ich jetzt mal sagen. Spannend wird es an der Stelle, wenn ich halt sage, okay, ein Container ist eine virtuelle Maschine, ich darf alles damit machen, was ich auch irgendwie in einer virtuellen Maschine mache.

Mein Anmender kriegt irgendwie Route-Rechte usw. und irgendwie Vollzugriff. Dann brauche ich mich nach der Zielweise jetzt nicht unbedingt wundern, wenn da irgendwie was schief geht. Ansonsten, woher kommt denn so ein bisschen der schlechte Ruf? Das Ganze hat gut angefangen mit dem Docker-Schocker, war im Prinzip einfach ein Exploit auf etwas betagteren Docker-Versionen,

auf betagten Linux-Distributionen, was dann einfach dazu geführt hat, dass man sehr, sehr einfach aus dem Container hat ausbrechen können, irgendwie sich die ITC-PassWD angucken und was man alles so machen kann. Insofern aber ein anderes Problem ist meiner Meinung nach der Aspekt hier der Missverständnisse. Da nehme ich immer ganz gern wieder das folgende Beispiel her,

nicht um mich über die Dame lustig zu machen, also die war lange Zeit irgendwie treues Mitglied der Docker-Community, sondern einfach um so ein bisschen zu zeigen, dass man sich manchmal ein bisschen bremsen können sollte, was irgendwie so Differenz zwischen was denn technisch geht und was man machen sollte irgendwie da einfach einhalten sollte.

Von der Jessie Frizzell gibt es den wunderbaren Blogpost Docker-Containers on the Desktop. Der Aufhänger war quasi, ja, sie hat früher einen Mac gehabt, da gab es ja diese Sandboxen und wäre ja schön, wenn es unter Linux sowas auch gäbe. Also sie sagt nicht, dass Container irgendwie Sandboxen sind, sie bedauerte einfach nur den Umstand, dass sie das gerne hätte

und sie würde jetzt mal anfangen, ihre Desktop-Umgebung zu containerisieren und sie fängt so an mit ihrem E-Mail klein, also matt, dann stellt sie irgendwie fest, ah, damit das tut, brauche ich ja noch meine Config, dann fängt sie an, die Config reinzugeben. Dann will sie irgendwie Skype machen, merkt, okay, brauche ich eine Videokamera, brauche ich Audio und so gibt sie halt die entsprechenden Devices rein

und so steigert sich das dann, glaube ich, in 10 oder 12 Experimenten und so ihr Fazit, wo sie meinte, sie wäre mein Blon gewesen, war das, als sie irgendwie Gparte D im Container irgendwie starten konnte und ihre Festplatte partitionieren konnte. Ist letztendlich keine Magie, was an der Stelle passiert ist, es funktioniert genau wie sollte, was sie macht, sie gibt hier Dev-SDA irgendwie rein,

stellt das im Container zur Verfügung und ja gut, dann kann sie da an der Stelle auch losliegen. Das Schöne an der Stelle, also nur um nochmal zu zeigen, in der Sandbox wäre sowas eher nicht möglich. Ja, das Schöne war letztendlich die Diskussion, was das Ganze dann losgetreten hat, also man hat ja generell davon abgeraten, irgendwelche X11-Anwendungen irgendwie zu containerisieren

und sie mögen nach Möglichkeit auch nicht ausprobieren, was passiert, wenn sie irgendwie einen Docker Run macht und das Route-Verzeichnis ihres Host-Systems in einen Container reingebracht nach TMP und dann mal anfängt, rekursiv unter TMP im Container zu löschen, ist halt keine Sandbox und wenn ich das halt mache, was technisch möglich ist,

dann kann halt sein, dass ich mir ins Knie schieße. Ja, insofern noch ein bisschen weiter gespielt mit irgendwie Nettigkeiten, wenn ich in einer NFS-Umgebung bin und mir einfach mal anschauen möchte, was irgendwie ein anderer User irgendwie in seinem Home liegen hat, wo ich letztendlich irgendwie nicht reingucken darf oder reinschreiben darf,

mit entsprechender Config geht sowas dann halt auch. Insofern, wir erinnern uns, Container keine magische virtuell Maschine, was anderes. Ansonsten auch noch ein großes Thema ist Unpatchable Narrowbilities, gerade in einer Zeit, wo immer mal wieder sowas um die Ecke kommt, also irgendwie Shellshock, was wir da alles noch haben, Harpleet und Co,

ist der Linux relativ gut durchgeschüttelt worden. Neben dem Docker Hub, also der größten Registry für Images, gibt es auch eine DKLO, da haben sie mal eine Statistik gemacht zum bestimmten Zeitpunkt hier, wie viele Images da auf Ghosts irgendwie anfällig waren, das Ergebnis war, sieht es jetzt nicht so doll, waren irgendwie zwei Drittel

und waren darauf anfällig. Bei Harpleet waren es dann 80%. Also ich kann nicht sagen, wie zeitnah nach dem Auftreten das Ganze war, aber eigentlich ist viel spannender die Ursache meiner Meinung nach, einfach vor dem Hintergrund, dass die meisten Container so auf den gleichen Basis Images aufbauen.

Wir haben irgendwelche Images wie CentOS, wir haben Ubuntu, was halt irgendwie 30 Millionen Puls irgendwie hat und ja, die Leute bauen halt auf diesen Images ganz gern ihre esoterischen Images auf und dann ist halt das Problem, die Welt dreht sich weiter, also sprich, dieses Basis Image hier wird aktualisiert, aber wer garantiert mir letztendlich, dass das esoterische Image,

das ich vielleicht einsetzen möchte, dann da auch wirklich mitzieht. Also insofern, das ist der Hintergrund, wenn man es weiß, ist es jetzt nicht so unglaublich dramatisch, soll einfach dazu anhalten, dass man dann, wenn man schon irgendwie sich die Images nicht irgendwie selbst baut, da halt einfach hinterher ist und quasi ein Upstream dran bleibt.

Also insofern, ja, alles blöd in der Containerwelt, nicht unbedingt. So ab 2015 hat sich meiner Meinung nach da ziemlich, ziemlich viel getan, also Jerome hat irgendwie ja seinen Vorsatz, dass sie da aufholen wollen, ja, eingehalten.

Insofern, ihr Ansatz oder dieses Propagent ist quasi Defense in Depths, also einfach, dass man mehrere Schichten an Sicherheitsmaßnahmen an der Stelle hat, so das Mantra bei Docker ist Secure Platform, Secure Access, Secure Content und dann schauen wir uns das mal im Detail an, also so als Grundlage für das Ganze, mal eine kontenerisierte HPC-Umgebung,

einfach, dass wir hier unterschiedliche Schichten haben, wir haben die Container-Runtime, wir haben Source-Betriebssystem, wir haben da oben eine Applikation laufen, wir haben keine Orchestrierungen und dergleichen, aber das möchte ich jetzt einfach mal kurz vorstellen, was es da so an Möglichkeiten auf den einzelnen Schichten gibt.

Genau, und Plan ist es einfach so, die nächsten 20 Minuten über die einzelnen Schichten drüber zu gehen und die Lösung mal so ansatzweise irgendwie vorzustellen. Insofern, bloß noch mal so als Aufhänger noch mal alles schön auf einer Seite. Fangen wir mal an mit dem Provision Mode, also um die Bereitstellung der Images und deren Verteilung.

Ja, was wollte ich jetzt hier sagen? Genau, auch wenn es relativ viele Anlaufstellen für Images gibt, ist der Docker Hub eigentlich immer noch so die Hauptanlaufstelle mit irgendwie, ich glaube, 100.000 Images, waren es zumindest letztes Jahr, dieses Jahr sind es vermutlich ein paar mehr, ja, also fangen da immer mehr an, sich Richtung Enterprise zu orientieren, mit irgendwelchen Abo-Modellen, wo man dann auch irgendwie Zusatzfeatures irgendwie mit dazu buchen kann,

ist vielleicht nicht unbedingt für jeden interessant. Was aber für die meisten halt interessant ist, ist zum Beispiel so was zu wissen, dass es irgendwie Official Repositories gibt, das sind die mit diesem Sternchen dran, das sagt jetzt endlich aus, dass die Images quasi kuratiert sind, dass es da einen gibt, der die regelmäßig aktualisiert.

In den meisten Fällen ist es die Distribution, die dann da auch eingesetzt wird und der Gedanke ist halt einfach, ja, dass man diesen Images zumindest so weit vertrauen können sollte, wie man das der eigentlichen Distribution an der Stelle tut. Ansonsten habe ich die Möglichkeit, wie quasi den Docker Hub irgendwie lokal hinzustellen, nennt sich irgendwie Trusted Registries,

ich habe die Möglichkeit zum Image sein und das Ganze dann auch zu verifizieren, also einfach um sicherzustellen, dass das Image, was ich irgendwie starten möchte, letztendlich auch das ist, was der Entwickler paketiert hat. Es gibt hier, um den App Store Gedanken noch weiter zu treiben, inzwischen auch ein Docker Store, die Werbebroschüre hat das dann irgendwie als, wie haben Sie es genannt,

Marketplace was compliant commercially supported software, Trusted Verified Publishers, alles schön, alles gut, wollen sie letztendlich aber an der Stelle auch irgendwie Geld dafür sehen. Ansonsten habe ich noch quasi mit einem kleinen Abo die Option, mir eine Private Registry anzulegen, aber da bin ich dann etwas in meinen Optionen limitiert,

also insofern der Königsweg, wenn man sich das mehr oder weniger leisten kann, ist halt einfach, sich eine Registry oder beziehungsweise ein Repository neben der Registry lokal hinzustellen und einfach vor dem Hintergedanken mit den Basis-Images einfach darauf zu achten, dass die Images irgendwie aktuell sind, also hier kuratiert genannt.

Insofern, wenn ich dann auch nur auf den Docker Hub gehen möchte, mich nach Möglichkeit irgendwie auf die Official Repositories zu limitieren, da gibt es ja auch einiges. Ansonsten ja, wenn ich das eigenverantwortlich verwalten möchte, will ich dann auch sowas haben, wie irgendwie den Image-Content überprüfen. Da gibt es mehrere Lösungen. Was ich relativ nett finde, ist der Claire,

ist aus dem Core-S-Projekt, der ist in die Registry-KRO integriert, wird dazu eingesetzt, um da jedes neue Image irgendwie zu überprüfen und kontinuierlich einfach, ja, wenn eine neue Schmachstelle rausgemeldet wurde, dann über die Images drüber zu gehen und die entsprechend zu flaggen. Es gibt da diverse Alternativen dazu, größtenteils kommerziell,

also Docker hat im Docker Hub, je nach Abo-Modell gibt es da dann irgendwie das Docker-Security-Scanning. Über OpenShift-Einsätze gibt es dann irgendwie Red Hat Cloudforms mit Openscap-Image-Scanning und auch für IBM Bluemix, was ich ehrlich gesagt nicht wirklich kenne, gibt es einen Vulnerability Advisor. Also Konzept ist meiner Meinung nach in der Regel immer ähnlich.

Sie unterscheiden sich halt einfach so ein bisschen in Features. Bei Claire sieht das so aus, wir haben hier unser Image. Ein Image besteht aus mehreren aufeinander aufbauenden Image-Layern. Und was das Tool macht, es geht halt einfach die ganzen Layer durch, schaut in die Paket-Datenbanken rein und baut sich eine Bill of Material auf,

auf Basis dieser ganzen Paketinformation, was auf dem System installiert ist. Dann zieht es los und schaut in die CVE-Datenbanken, die Hersteller rein, was da für Schmachstellen gemeldet ist und ja, flaggt dann die Layer bzw. die Images entsprechend. Nachteil an der Sache ist,

schlägt natürlich nicht bei Handys installiertes Software an. Also sprich, wenn ich da irgendwie noch per Wege in mein Image irgendwie was rein habe oder sonst irgendwie reinkopiert, ja, das wird dann halt nicht geprüft. Ja, Schlangenöl und dergleichen habe ich auch nicht dabei. Also wenn ich in einer Firma bin, die halt erfordert, da sämtliche eingesetzte Software irgendwie von mindestens zwei Wien-Scannern geprüft ist,

ist hier zumindest nicht so sauber integriert, da müsste man dann irgendwie extern machen. So eine Abfrage auf Lizenzsoftware oder von mir aus über irgendwelche Check-Summen, ob irgendwie komische Software drauf ist oder dergleichen, ist auch nicht dabei. Und so Compliance-Aspekt, da muss man dann auch irgendwie andere Werkzeuge

als Clare sich anschauen. Aber zumindestens für CVE-Datenbanken, wenn man irgendwie Red Hat, Ubuntu, Debian und inzwischen ist, glaube ich, noch mal ein, zwei Distributionen mehr dazugekommen, einsetzt, dann fährt man damit eigentlich relativ gut. Ja, im Operation Mode auf dem Host, wie gesagt, hatten wir vorhin schon Control Groups

und Namespaces als erste Instanz, um irgendwie abzusichern. Isolierter Betrieb, dass einfach der Container bzw. die Prozesse im Containerdenken also das System weitergehend allein für sich haben. Limitieren vom Ressourcenverbrauch, hatte ich ja vorhin schon angeschnitten. Ansonsten gibt es die Kernel Capabilities und die Option zum Kernel Hardening.

Ganz vereinfacht gesagt, die Capabilities sind eine Möglichkeit, um ja relativ grob einzelne Berechtigungen zu vergeben, was jetzt irgendwie ein Prozess machen kann, was er nicht machen kann. Gibt es halt Linux 2.2, also auch schon ein bisschen. Auch nicht mehr ganz Bleeding Edge bzw. halt keine

komplett neue Technologie. Und so kann ich zum Beispiel vermeiden, dass irgendwie ein Container pingt. Klingt schon mal ganz sinnvoll, um irgendwie zu vermeiden, dass er irgendwie sich im Netzwerk auf Erkundungszube gibt oder, wenn ich sowas möchte, die entsprechende Capability freischalten, dass irgendwie im Container ein Kernelmodul geladen werden kann, wenn ich denn sowas möchte.

Das Optimum wäre natürlich alles wegschmeißen und nur aktivieren, was man letztendlich braucht. Das Problem an der Sache ist aber, ich habe dann so ein gewisses Trial and Error, was ich irgendwie wegschmeißen kann. Und was nicht, also für den Normalsterblichen ist das jetzt glaube ich nicht unbedingt der optimale Ansatz. Wenn das ganze Update rauskommt, kann sein, dass ich mit den gleichen Settings

wie vorher irgendwie nicht so glücklich fahre. Da gerade nochmal kurz zu den Capabilities irgendwie ein Beispiel. Standardmäßig kann ich den Hostname im Container nicht setzen, wenn ich das haben möchte. Muss ich hier die CapSysAdmin freischalten. Ist ein bisschen unglücklich, weil die relativ weit gefasst ist und man da alles andere, alles mögliche andere auch noch mitmachen kann. Aber so kann ich dann halt im Container

meinen Hostname ändern, wenn ich das aktiviert habe. Ja ansonsten, für die ganz harten Kernel Hardening, es gibt die GR Security und die PRX Patches, also einfach um die Chance für einen Angreifer auf irgendwelche Buffer Overflows zu reduzieren. Oder wenn ich irgendwie Role-Based Access Control und Auditing nachrüsten möchte.

Wie gesagt, also ist eher jetzt für die Spezialfälle, also würde ich jetzt einem kompletten Anfänger, oder weiß ich nicht, also würde ich nicht irgendwie so zum Einstieg als Absicherungsmaßnahme wählen. So im HPC-Bereich mag man sowas auch nicht so ganz gern, weil da teilweise dann kurze Laufzeit generiert wird, was dann irgendwie als Buffer Overflow

Angriff erkannt werden könnte und dergleichen. Und ja, insofern, was meiner Meinung nach wesentlich sinnvoller ist, ist die ganze mandatory Access Control-Geschichte, also SE Linux und App Armor. Nur so im Schnelldurchgang, gibt es auch später direkt im Anschluss, glaube ich im H8 drüben noch einen Vortrag dazu.

Insofern, hier nur so der ganz kurze Anriss. Ja, die meisten werden denke ich mal SE Linux kennen oder zumindestens wissen, wo man es deaktiviert. Ja, vereinfacht gesagt, Ziel von App Armor und SE Linux ist letztendlich das gleiche, dass ich halt den Zugriff auf bestimmte Dateien und Pfade einfach irgendwie limitiere.

Und ja, die beiden Werkzeuge sind in der Regel bei der Distro dabei. Klar, bin ich unbedingt beide gleichzeitig aktiv. Aber was irgendwie sehr, sehr nett ist, ja, sie bringen in der Regel dann, wenn man irgendwie Docker installiert, dann auch die entsprechenden Policies irgendwie mit, um den Container zu schützen bzw. um den Hostform-

Container zu schützen oder andere Container vor irgendwie einem böswilligen Container. Ja, also meiner Meinung nach ist das eigentlich auf jeden Fall eine Technologie, die man in so einem Umfeld irgendwie einsetzen möchte und ja, einfach das Risiko der rechte Ausweitung durch weiteres Limitieren vom Ressourcenzugriff

einzuschränken. Insofern gerade in so Szenarien, wo ich vielleicht keine Usernamespaces irgendwie einsetzen kann, das ist irgendwie so die Policy, die da irgendwie standardmäßig irgendwie mitkommt. Ist bloß, wenn es interessiert, kann man da noch angucken von der Jessy Frisell, von der wir es vorhin auf dem Desktop hatten. Die hatte da noch irgendwie ein App Armor Custom Profile Generator

irgendwie sich gebaut, namens Bain. Ich bin mir aber nicht mehr so ganz sicher, inwieweit der noch weiterentwickelt wird. Also ich habe da schon lange nichts Neues mehr irgendwie gesehen. Ja, ansonsten, wenn man zumindest mitbekommen möchte, wenn irgendwie was Böses passiert, ist eigentlich das Linux Auditing-System ganz nett,

das einfach dazu genutzt werden kann, um Zugriffe ja, und bestimmte Aktionen einfach zu protokollieren. Also ganz wichtig ist kein Enforcement, sprich der Zugriff wird nicht irgendwie verboten. Das muss ich ja nicht mit FC Linux oder dergleichen machen, sondern einfach nur die Protokollierung. Hier mal irgendwie so ein Beispiel, wie ich auf dem Host alle Löschzugriffe oder die Modifikation der

ETCPassWD irgendwie mir protokollieren lassen kann und so weiter. Und im Containerumfeld möchte ich da zum Beispiel halt einfach so diese Lifecycle-relevanten Aktionen irgendwie dokumentieren, damit ich dann noch nachvollziehen kann, wer jetzt irgendwie einen Container gestartet hat, wer der böse war und wenn sich irgendwelche Zertifikate, Keyes und dergleichen irgendwie ändern.

Insofern, also sowas sollte man eigentlich in bestehende Audits irgendwie einbinden, wenn man sowas schon hat. Und dann auch irgendwie klassifiziert irgendwie so ein Stück weit ins Monitoring mit reingeben. Ja, ansonsten bezüglich Compliance und dergleichen OpenSCAP oder SCAP oder wie auch immer man's ausspricht, da gibt's auch ein Paket für

Docker dafür und ist inzwischen Teil von OpenSCAP Docker, nennt sich das Ganze und ja, das ist von der Funktionalität teilweise ein bisschen ähnlich zu Clare. Klar ist der Fokus auf diesen auf diesen SCAP Policies, aber ich hab hier zusätzlich noch die Option, dass ich einen Image-Scanner

irgendwie mit drin hab und da zumindest in SlotDoco ausprobiert hab, hab ich's leider noch nicht, auch laufende Container scannen kann. Also schonmal eine nette Sache. Einschränkung an der Sache, während hingegen Clare auch mit irgendwie andere ja, Geschichten noch unterstützt, ist hier wohl explizit nur Docker unterstützt. Und so wie's aussieht, ist das letztendlich das,

was auch irgendwie in Red Hat OpenShift eingesetzt wird. Ja, der Docker Bench for Security ist eigentlich ein relativ nettes Tool, wenn man einfach mal so schauen möchte, wie ist denn so mein Container Host konfiguriert, was jetzt irgendwie best practices angeht und was so Konfigurationsempfehlungen generell angeht,

gibt's auch als ein Container, der ist allerdings relativ privilegiert zu starten. Klar, nachvollziehbar, sonst kommt er nicht an die ganzen Ressourcen. Was man sich hier zum Beispiel vorstellen könnte, ist, dass man so einen Scan als irgendwie Vorbedingungen für besonders sicherheitskritische Images aktiviert, sodass der Container dann nur irgendwie startet, wenn der Check erfolgreich

passiert, ja, erfolgreich passiert wurde. Und so sieht dann letztendlich der Output aus. Wie die Checks zustande kommen, zeige ich später noch. Der basiert auf so einem CRS Guide, der ist hier als Basis genutzt und wird zum Beispiel hier überprüft, ob der Kern hinreichend aktuell ist, ob die Docker-Version hinreichend aktuell ist, ob der

DemonTLS macht und so weiter. Und ja, wie gesagt, läuft auch als Container. Aufruf sieht dann so aus, also darf dann relativ viel machen letztendlich, aber ja, ist der Natur der Sache leider irgendwie inhärent. Insofern, was gibt es noch auf der Container Runtime an neuen Optionen? Bei Version

1.1.0 kamen die Authorization Plugins dazu. Das heißt, oder beziehungsweise standardmäßig, wer Zugriff auf die Docker-Commandline hat, kann im Prinzip sämtliche Optionen machen. Also da gibt es nicht nochmal irgendwie eine separate Trennung, wer jetzt irgendwie was darf, außer ich

habe mir da irgendwie in Form von Sudo-Skripten irgendwie was drumrum gebaut. Das heißt, dass ich dann halt, ja, so mehr oder weniger das Äquivalent dazu, wenn ich da Mitglied der Docker-Gruppe war, war ich mehr oder weniger gut auf dem System, einfach dadurch, dass ich mir halt entsprechende Aufrufe quasi bauen konnte und Sachen irgendwie reingeben und mehr Sachen machen, als ich eigentlich hätte geduft,

standardmäßig. Und ja, inzwischen gibt es halt einfach die Möglichkeit, so Authorization Plugins zu nutzen. Und da hat man dann die Möglichkeit, verschiedene User-Gruppen quasi zu definieren und zu sagen, hey, ich habe hier nur, ich habe hier User, die nur Lockfiles irgendwie lesen können und der hier darf dann aber irgendwie Container

starten und so weiter, um das einfach voneinander abzugrenzen. Sprich, ich kann hier einfach Robes Access-Control nachrüsten. Das ist auf jeden Fall was, was man irgendwie einsetzen möchte, wenn irgendwie mehrere Parteien Zugriff auf dem gleichen System auf die Geschichte haben. Ja, ansonsten die User-Namespaces,

ein ganz großes Thema, das irgendwie relativ dringend erwartet wurde, kam auch in der Version 1.1.0 rein. Also da ist es wirklich rund gegangen. Und ja, die User-Namespaces sind vereinfacht gesagt da, um zu verhindern, dass root im Container root auf dem Host ist. Und ich dann im Container zu viel Kram machen kann, wenn ich dann mal irgendwie Zeug in Container reingegeben

habe, was da eigentlich nicht unbedingt rein sollte. Da ist der Phil Estos nicht ganz unschuldig dran. Der war da einer der mit Hauptentwickler. Von dem habe ich mal so ein paar Folien geklaut. Um es vorweg zu nehmen, die User-Namespaces sind momentan noch nicht in dem Status, in dem man es dann irgendwie final haben möchte. Aber es ist momentan schon

ein ziemlicher Schritt in die richtige Richtung. Einfach vor dem Hintergrund, dass es ein Problem hat, dass root im Container dann im Zweifelsfall root außerhalb ist. Und deswegen möchte ich halt User-Namespaces haben. Und ja, vor dem Hintergrund möchte ich auch eigentlich keine User als root irgendwie im Container arbeiten lassen. Also das war das Szenario, was ich vorhin erwähnt habe, dass dann Prozesse

unter einer anderen User-ID als root bitte tunlich im Container laufen sollten. Und ja, mit den User-Namespaces habe ich einfach die Möglichkeit, den root im Container auf eine andere User-ID als root außerhalb zu mappen. Also die Einführung war wohl nicht so ganz trivial, da letztendlich in sehr, sehr vielen Stellen irgendwie geschraubt werden musste. Momentan sind sie irgendwie

mit der Phase 1 durch. Das heißt, es ist ein Remapping auf demen Instanz möglich. Ist ja schonmal ein Anfang, hat allerdings den Nachteil, dass für alle Container, die ich durch diesen Demon gestartet habe, das gleiche Mapping existiert. Ja, aber wie gesagt, ist jetzt momentan mal so ein Anfang. Die Phase 2 wird dann ein Remapping

auf Container-Basis ermöglichen. Und ist eigentlich das, was man dann halt irgendwie in einer Multitenancy-Umgebung einsetzen möchte. Genau, und da sind sie momentan gerade dran. Ansonsten, was meiner Meinung nach sehr, sehr cool ist, sind die Recon Profiles. Das ist generell eine sehr nette Sache. Linux Secure Computing ist auch eine

der Möglichkeiten, die ich irgendwie einsetzen kann. Im Prinzip völlig losgelöst, wie auch die Namespace-Geschichte oder irgendwie die C Groups losgelöst vom Container-Einsatz. Es ist so Basic Sandboxing, was einfach verhindern soll, dass bestimmte Sys-Calls aus dem Container raus aufgerufen werden können.

Und die Policy lässt sich direkt beim Starten vom Container mit übergeben. Und kann ich dann zum Beispiel verhindern, dass irgendwie ein bestimmter Container chmod irgendwie machen kann und dergleichen er kriegt dann Operation Not Permitted zurück. In der Default Policy ist es momentan so, die mit ausgeliefert wird, es werden 44 System-Calls von irgendwie

Größenordnung 313 auf dem 64-bit Linux momentan blockiert. Beispielsweise haben sie einen Reboot-Call irgendwie abgeklemmt. Das heißt, dass ich dann nicht einfach aus dem Container raus irgendwie mein Source-System irgendwie rebooten kann. Das ist eigentlich nicht so unbedingt, was man haben möchte. Haken an der Sache ist,

es gibt noch 270 nicht geblockte und die Zahl wird mit großer Wahrscheinlichkeit auch nicht unbedingt kleiner werden, einfach weil da sehr von dem, was sich im Container laufen hat, abhängig ist, was der denn braucht, dass es überhaupt noch funktioniert. Insofern wird sich diese Anzahl sehr, sehr schwer reduzieren und hier hätte ich

halt auch wieder die Möglichkeit, dass ich quasi irgendwie so eine Lernphase irgendwie vorschalte, wo ich dann protokolliere, welche Sys-Call sie irgendwie aufruft und dann letztendlich nur die irgendwie freischalte. Genau, aber dann viel Spaß damit rauszufinden, warum bestimmter Call jetzt irgendwie gebraucht wurde, wenn es dann mal irgendwie an der Stelle

nicht mehr tut. Hier ist einfach nochmal so eine Übersicht, was standardmäßig geblockt ist, zum Beispiel diese ganzen Time-Geschichten, dass die Uhrzeit im Container angepasst werden kann, ist hier entsprechend geblockt. Einfach vor dem Hintergrund, das hatte ich ja vorhin schon erwähnt, dass bei denen das momentan noch nicht alles irgendwie Genamespaced wäre und eben

die Time-Namespaces noch so eine zukünftige Erweiterung wären, die man eigentlich ganz gerne hätte und deswegen wird das dann letztendlich an der Stelle blockiert, wie halt einfach auch irgendwie die SE-Linux-Geschichten genutzt werden, um einfach so ein paar Unzulänglichkeiten, die es noch gibt, zu kaschieren, würde ich jetzt an der Stelle mal sagen.

Genau, was auch nett ist, wie gesagt, ich kann das auf Container-Basis machen, das heißt, ich kann Container mit unterschiedlichen Second-Profiles laufen lassen, das heißt, Container A kann mehr Rechte haben als Container B und so weiter. Ja, meiner Meinung nach wäre es relativ nett, wenn irgendwie die Image-Maintener oder gar die Developer irgendwie so eine Liste von

Syscalls, diese brauchen irgendwie gleich irgendwie so mit in die Image-Beschreibung packen könnten und das man auf Basis von dem dann halt irgendwie loslegen kann. Wäre eigentlich noch eine wünschenswerte Verbesserung. Ja, ansonsten, was gibt es sonst noch? Sehr viel Kleinkram, zum Beispiel gibt es jetzt irgendwie ein PID-Limit, den ich dazu einsetzen

kann, um irgendwie Fork-Bombs irgendwie aus dem Container raus zu verhindern. Ja, dass halt ein Container das ganze Host-System irgendwie wegbombt. Es gibt noch diese Security-Option, no new privileges, was einfach ein Stück weit die rechte Eskalation einschränkt. Ich kann meine Container irgendwie read-only machen, was ganz nett ist, wenn

ich verhindern möchte, dass ich irgendwie einen Angriff irgendwie fortpflanze, quasi. Ja, insofern, also gibt es relativ viele Nettigkeiten, die da unterwegs sind. Worüber ich neulich gestolpert bin, ist dieses Paper hier, da geht es um den Linux-Container-Shield, kurz Lick-Shield, und ja, der Gedanke ist, dann machen wir auch so eine Lernphase

und generieren auf Basis von dem dann App Armor Rules. Das ist eigentlich relativ nett, weil im Vergleich zu irgendwie, wenn ich quasi im Lauf eine Betrieb-Anomalie- Erkennung und dergleich machen möchte, habe ich dieses Ding einmal, setze dann hinterher die Policy scharf und bin dann damit unterwegs.

Und ja, großer Nachteil an der Sache ist, sowas schützt mich natürlich nicht vor irgendwie validen Angriffen. Also sprich, wenn ich irgendwie einen Datenbank- sonst irgendwie 5000 Zugriffe hat und dann auf einmal irgendwie 20.000 pro Zeiteinheit sowas erkenne ich da halt, damit natürlich nicht bzw. kann ich somit halt nicht blockieren, aber einfach, wenn ich mir die App Armor

Rules-Generierung da letztendlich vereinfachen möchte, kann ich sowas einsetzen. Ja, ansonsten ist nur der Application Layer offen. Da kann man sich im Prinzip auszoben, wie man möchte. Nachteil ist, es gibt da relativ wenig Fertiges, was man einfach irgendwie so anklickt und dann läuft das. Und dabei ist eigentlich gerade so die Übermachung irgendwie auf Applikationsebene, wir sind

Container prädestiniert dafür, einfach vor dem Hintergrund, dass ich vom Host aus sehr, sehr, sehr, sehr genau sehe, was irgendwie im Container passiert. Wenn ich irgendwie in Hypervisor einsetze, sehe ich das vom Hostsystem jetzt nicht unbedingt, was im Container wirklich auf Prozess-Ebene, auf Syscall-Ebene passiert. Da müsste ich dann schon irgendwie einen Agenten

in der virtuellen Maschine haben. Da sehe ich dann halt extern im Zweifelsfall nur, wie viel Memorie er hat, wie viel CPU er gerade braucht und so weiter. Also da habe ich schon weitaus weitreichendere Möglichkeiten, wenn ich sowas irgendwie containerisiert letztendlich machen möchte. Genau, das hatte ich gerade schon erwähnt, da gibt zum Beispiel Einsatz, irgendwie

Ansatz. Da hat er so ein, ja, da protokollieren sie einfach, die Syscalls, die irgendwie reinkommen und haben dann so eine Art Sliding-Window, also er protokolliert immer nur ein bestimmtes Zeitfenster und so weiter und vergleicht dann, ob das, was jetzt auf dem System grad passiert, noch dem entspricht, was er quasi vor zwei Minuten noch irgendwie

aufgenommen hat und wenn das irgendwie bestimmte Parameter quasi verletzt, dann habe ich eine Anomalie und dann passiert unter Umständen was Böses. Sowas kann ich halt dann einfach dazu einsetzen, wenn ich irgendwie sowas nutzen möchte, wie mit der Datenbank, um zu erkennen, wenn ich auf einmal irgendwie ganz, ganz viele Datenbankabfragen bekommen und auf einmal irgendwie meine, ja, meine

Kundendaten irgendwie abziehen möchte. Insofern, in dem Kontext gibt es dann auch noch Sysdig. Komme ich gleich noch dazu. Da gibt es auch noch ein Paper im Bereich Anomalieerkennung beziehungsweise in Kombination mit irgendwie Alerting und Incident Response. Was aber auch noch interessant ist, sind geplante Verbesserungen, so ein Blick in die Zukunft,

wo man hin möchte, ist einfach Fully Unprivileged Containers zu haben, also sprich, ich kann einen Container starten, ja, durch einen Non-Root User, ohne dass er irgendwie in irgendeiner Weise eine Rechterweiterung braucht. Da ist in letzter Zeit einiges in Bewegung, aber ja, ist noch ein relativ langer Weg dahin. Aber das ist meiner Meinung nach so ein bisschen das

Aimziel, was man irgendwie verfolgen sollte. Dann gibt es noch die Phase 2 der Usernamespaces, das hatte ich ja schon angeschnitten. Anfört, dass es ein Custom Namespace pro Container gibt. Momentan ist es so, dass es upstreammäßig im Kernel quasi der Support schon da ist. Und ja, man möchte halt irgendwie sowas einsetzen, wenn man

eine Multi-Tent Umgebung hat, um dann quasi pro Kunde New ID oder Group ID Remapping machen zu können. Ansonsten, ja, wo sie auch noch so ein bisschen dran sind, sind irgendwie Sicherheitsfeatures by default zu aktivieren, gerade sowas wie Content Trust. Und ich glaube die Usernamespaces, weiß nicht, ob sie inzwischen standardmäßig aktiv sind, vermutlich nicht, aber die waren auch

zumindest eine lange Zeit nicht aktiv. Und war zwar alles da, aber ist halt nicht genutzt worden. Und da sollte man dann auch schon wirklich darauf achten, dass die Features, die man einsetzen möchte, dann auch wirklich aktiviert sind und sich dann nicht unbedingt jetzt auf die Docker-Jungs verlassen, dass das alles standardmäßig schon scharf geschaltet ist. Ansonsten, was sonst noch

geschah mit Docker Secrets in der Version 1.1.13, kam eine Option dazu, Passwörter in einen Container reinzugeben, beispielsweise wenn ich eine Applikation habe, die auf einen Datenbank-Server irgendwie verbinden möchte. Der unschöne Weg ist sowas irgendwie über Umgebungsvariaten zu machen, das ist aber eher full. Ja, jetzt gibt es ja in Docker Swarm

einen entsprechenden Dienst dafür, der das macht. Nachteil ist halt an der Stelle, ich brauche Docker Swarm dafür. Kann ich aber letztendlich auch denn nur mit einem Container machen, also ich brauche nicht unbedingt zwangsweise irgendwie dutzende Containern. Und ja, also das ist noch eine Neuerung, die irgendwie reingekommen ist. Und was ich selbst nicht kannte

bis irgendwie Februar diesen Jahres, war Systic bzw. Systic Falco. Und gerade für den Anomalie-Erkennungsbereich ist das eigentlich ziemlich schick. Ja, Systic ist von einem der Co-Creator von Wireshark gestartet worden. Und im Prinzip ist es eine Kombination aus S-Trace, H-Top, If-Top,

L-Soft, Transaction Tracing und noch irgendwie Magie außenrum. Und das Ganze funktioniert so, es ist ein Kernmodul und kriegt dann der Natur der Sache bedingt relativ gut mit, was denn da so alles passiert, also sprich ich starte eine Applikation, worauf greife die zu, was für Netzwerkverbindungen macht die auf,

keine Ahnung, was für File ist, Krypta hat die offen und den ganzen Kram. Und was zusätzlich nett ist, sie haben quasi Filter auf Container-Basis. Das heißt, ich kann mir dann relativ genau angucken, was alles irgendwie im Container passiert. Und ich kann also unterstützen eben Docker, LXC und Rocket vermutlich inzwischen auch. Also das ist eine sehr, sehr nette Option, um irgendwie

sehr detailliert den Containern irgendwie auf die Finger oder generell Prozessen auf die Finger zu schauen, was denn da gerade auf dem System irgendwie los ist. Genau. Und darauf aufbauen gibt es jetzt auch noch Systic Falco, das ist relativ neu. Ja, ist so ein bisschen Anomalide- Erkennung bzw. einfach

rein, wenn irgendwie was Komisches ist. Ja, bringt standardmäßig irgendwie so ein paar Regeln mit, zum Beispiel Abprüfung, ob in einem Container irgendwie... Ist das normal? Ja, nicht bewegen. Nichts

gemacht. Insofern, wir sind eh fast durch. Nee, aber ob in einem Container irgendwie eine Shell gestartet wird, sowas möchte ich ja vielleicht nicht unbedingt haben, wenn ich irgendwie eine Web-Applikation habe, dass da auf einmal irgendwie eine Shell aufgeht, die sich da irgendwie einen User irgendwie remote irgendwie drauf gestattet hat und so weiter. Da kann er dann irgendwie losbrüllen

oder wenn er auf irgendwie ungewöhnliche Verbindungen irgendwie aufmacht, die sonst irgendwie nicht da sind. Das hier fand ich irgendwie ganz süß. Anderer Prozess als Skype oder WebEx versucht auf die Kamera zuzugreifen. Also er guckt hier event-type gleich open, File Descriptor ist Video und der Prozessname ist

nicht Skype oder WebEx. Das heißt, wenn ich dann irgendwie ein Tool haben möchte und bin zumindest so mit diesen Standard Policies irgendwie vertraut, dann nenne ich halt mein Tool, was irgendwie den Angreifer, den User beobachtet, halt auch Skype. Also insofern ist durchaus noch irgendwie ausbaubar an der Stelle, was da geht. Aber es zeigt auf jeden Fall

mal was mit so einem Tool, wie irgendwie süßtig letztendlich irgendwie möglich ist. Ja, jetzt habe ich relativ viel erzählt, was es an Technologie gibt. Was auch noch spannend ist, ist der Punkt trotzdem. Ja, Prozesse. Worüber sollte man sich Gedanken machen? Beziehungsweise meiner Meinung nach sollte man in

der Containerwelt nicht unbedingt das Rad neu erfinden, weil es irgendwie gefühlt neue Technologie ist. Und da halt einfach loschlagen und alles über Bord werfen und alles irgendwie machen, was irgendwie schön ist und weil es so fluffig tut. Sondern halt einfach bestehende best practices übertragen. Ich meine Softwareverteilung und irgendwie Pflegen von irgendwelchen Software Repositories

unter Linux, weiß ich nicht wie lange gibt es RPM, wie lange gibt es dpkg und Konsorten. Also insofern, auch da muss man sich irgendwie um Gedanken drum machen. Also gerade das Thema Image Security ist halt ein relativ großes Thema. Und im Prinzip sind da letztendlich die gleichen Fragen wie mit jedem anderen Software Repository auch.

Ich muss überprüfen, wer das verwalten darf. Wie gehe ich irgendwie mit der Integration von Quellen mit dritten Quellen um? Wie scanne ich das Ganze? Prüfe ich, ob ich irgendwelche Systeme habe, die irgendwie nicht auf dem aktuellsten Stand sind und so weiter. Also

ist unterm Strich letztendlich nichts Neues. Wer darf neue Pakete bauen, analog? Wer darf neue Images bauen? Wie gehe ich mit der Signierungsgeschichte um? Wie mache ich das irgendwie mit Lifecycle Aspekten? Wie häufig patche ich? Hau ich das einfach so raus? Oder mache ich irgendwie ein Zeitfenster aus? Ganz wichtig, ich bin ja so

ein bisschen aus dem schwäbischen Bereich, Kehrwoche. Wenn man dann halt einfach feststellt, keine Ahnung, ein Image ist irgendwie ein Jahr lang nicht mehr verwendet worden, hat alle möglichen Sicherheitslücken, dann sollte man sich da durchaus mal Gedanken machen, ob man das nicht einfach wegputzt. Insofern, oder so Aspekte wie irgendwie so ein unternehmensweites Basis Image einfach zu pflegen,

sind durchaus Punkte, wo man sich Gedanken drüber machen sollte. Oder ja, der Aspekt, wie gehe ich mit Passwörtern um, wie bringe ich die Passwörter in die Applikation rein, hatte ich ja vorhin gesagt, gibt so ein bisschen was und gibt auch eine andere Lösung. Insofern, die Sachen muss man sich einfach auch irgendwie in einer normalen Umgebung Gedanken drum machen.

Ansonsten, Sicherheits- und Audits, hatte ich ja vorhin schon erzählt. Man sollte sich ja mindestens überlegen, wie man denn nachvollziehen möchte, wer jetzt wann welches Image gestartet hat, vielleicht auch wer das irgendwie paketiert hat, wo das Ganze herkommt, was das gemacht hat, wie sicher das Ganze ist. Und

vielleicht auch irgendwie mitzubekommen, was irgendwie in ein beendeter Container irgendwie so alles auf dem System vielleicht angerichtet hat. Und ja, das sind eigentlich viele Fragen, die auch irgendwie so in einer normalen Linux-Umgebung irgendwie zu beantworten sind. Und wohin logge ich? Was setze ich da ein? Das sind einfach Aspekte, die habe

ich normalerweise auch. Also insofern passend dazu, so ein Negativbeispiel, wie man es vielleicht nicht unbedingt machen sollte, ist das hier Fully Automated Build Process, weil es mit Containern so schön geht. What could possibly go wrong? Es soll durchaus Leute geben, die anfangen und sagen,

mit hier ihren Jenkins und keine Ahnung, was alles, was es da Schönes gibt, dass sie irgendwelche GitHub Seiten überwachen, wenn da irgendwie eine neue Version von einer Library oder sonst was rauskommt, die sich irgendwie besorgen und auf Basis von dem dann irgendwie sämtliche Images neu bauen, was ja schon mal löblich ist. Einfach, dass so Upstream up-to-date

bleiben und so weiter. Aber das dann durchaus irgendwie direkt irgendwie in Production reinschieben. Also da haben die Jungs mal so eine gewisse Untersuchung gemacht, ob ihnen das letztendlich dann irgendwie möglich ist. Da haben wir irgendwie einen GitHub Repository übernommen. Und ja, haben dann einfach mal geschaut, ob dann ihr Chartcode,

in Anführungszeichen, den sie eingebracht haben, dann wirklich irgendwie am Tag drauf irgendwie in Production zu finden ist, ohne dass irgendwie in irgendeiner Weise ein Review oder sonst irgendwas drüber gelaufen wäre. Und ja, Fazit ist, sie waren letztendlich erfolgreich. Also vor dem Hintergrund ein Kollege hat mal auf der Apache Big Data Conference irgendwie zu

Apache Big Top irgendwie einen Vortrag gehalten und sich da mal den Bildprozess angeguckt. Was denn da alles passiert, war der OlaFleppe. Also durchaus mal durchklicken ist sehr interessant. Und im Bildprozess werden da teilweise aus etwas dubioseren Quellen dann auch irgendwelche Exe-Files, um Symblings unter Windows machen zu können, aus irgendwelchen

ja, shady Webseiten quasi irgendwie runtergeladen und wenn man dann sich sowas überlegt und dann überlegt, dass man sowas dann direkt in Production irgendwie reinschiebt, ist relativ unschön an der Stelle auf jeden Fall. Ansonsten gibt es ja noch das Themengebiet der Orchestrierung und keine Ahnung was, was es da irgendwie alles schöne an Security-

Implikationen gibt. Da gibt es den netten Post dazu. Aber ich glaube, das überspringen wir hier. Ansonsten noch kurz weiterführendes. Wer sich noch ein bisschen wo einlesen möchte, so das älteste Ding aus dem Umfeld ist diese Introduction to Container Security von Docker, was einfach mal so die Basics irgendwie quasi nochmal irgendwie vorstellt und warum

das alles nicht ganz so unsicher ist. Und das hier ist inzwischen Vulnerability Exploitation in Docker Container Environments. Das ist auch noch interessant zu lesen. Einfach auch vor dem Hintergrund, da haben sie mal noch eine Umfrage gemacht, inwieweit denn jetzt welche Aspekte irgendwie bei Containern quasi

das Limitieren da sind. Und so die hat, Hauptpunkt war hier der Security Aspekt, das den Leuten davor irgendwie raus und gibt dann auch noch so ein paar Angriffsmöglichkeiten auf Docker Demon und so weiter. Und ja, ist eigentlich auch noch relativ nett zu lesen. Das hier ist auch noch schön. Das ist irgendwie

OpenShift-sponsored und gibt es bei O'Reilly Using Container Safety Safely in Production. Da wird dann nochmal erklärt, also es ist relativ einfache Kost, aber da wird dann nochmal erklärt, wie ich denn im Container ein Prozess unter einer anderen User ID als Wut starte und einfach nochmal so diese ganzen ja, Basisachen sozusagen.

Wer mal viel Zeit hat, ein schönes, langes, verregneres Wochenende ist und nicht gerade irgendwie Frostcon ist, kann sich mal das hier angucken. Gibt es inzwischen glaube ich die Version 1.1 von diesem NCC Group White Paper und Understanding and Hardening Linux Container. Ist ziemlich interessant. Das ist so

120 Seiten lang und da gehen sie dann halt zum Beispiel die ganzen Capabilities durch. Dies da gibt, bewerten die quasi, ob die standardmäßig erklären, was die denn für Funktionen haben, bewerten die, schauen, wie das bei LXC, Docker und Rocket ist und stellen das einfach so ein bisschen gegenüber und auch die

Vorkonfiguration, was jetzt in welche Version an ist. Das Problem ist ja Version 1.1 Version 1.11. Das ist schon eine Weile her. Insofern so Dokumente können eigentlich letztendlich nur der Entwicklung irgendwie hinterherhängen. Also, die man bei Docker mal irgendwie zwei Wochen in Urlaub war, hat man das Gefühl, man kommt da gar nicht mehr hinterher, was da irgendwie schon wieder alles Neues war.

Insofern, um zum Ende zu kommen, noch ganz kurz die DRS Docker Benchmark, das ist so das Trockendste, was man sich letztendlich antun kann. Das ist vom Aufbau quasi so. Ich habe die Anforderung, dass ich hier eine bestimmte Datei anschaue, dass sie bestimmte Permissions hat. Wie überprüfe ich das letztendlich, ob die diese Permissions hat?

Und wenn die diese Permissions nicht hat, wie setze ich diese Permissions? Also so ist der grundlegende Aufbau an diesem Ding hier. Und genau das ist im Prinzip das Dokument, was diesem Docker Benchmark da zugrunde liegt, also dem Programm bzw. dem Container, was man da halt nutzen kann. Das ist

quasi nochmal so die Textform davon, wenn man das irgendwie zu Hand, zu Fuß machen möchte. Ansonsten, was relativ neu ist, ist die Docker Reference Architecture Securing Docker Data Center and Security Best Practices. Ist alles zwar so ein bisschen mit Fokus auf ihren Enterprise angeboten, aber da ist zum Beispiel nochmal irgendwie erklärt, wie das mit

dem Raft-Sensus und hier Schlüsselaustausch und sonst irgendwie was funktioniert. Also ist relativ lesenswert auf jeden Fall. Ja, insofern Zusammenfassung und Fazit. Containers do not contain. Wenn man sich mal anschaut, was es denn so an Threats wie Denial of Service und so weiter gibt. Es gibt eigentlich für alles irgendwie ein Werkzeug,

das man letztendlich draufschmeißen kann. Auch irgendwie wenn quasi externe Angriffe, das davor war, irgendwie aus einem Container auf ein anderen oder ein Host. Es gibt sehr, sehr viele Möglichkeiten, was zu tun. Das Problem ist letztendlich, man muss es tun und dann wird es dann halt teilweise dann immer wieder schwierig, so Faktor Mensch und so.

Aber Werkzeuge sind da und ich wäre auch ein bisschen vorsichtig mit zu sagen, dass Container per se irgendwie unsicher sind. Das ist jetzt irgendwie ein Exploit. Irgendwann von letztes Jahr da ging es darum, einfach Hutrechte auf ein System zu bekommen und Fazit war dann letztendlich, nachdem der Exploit lief, war er dann halt irgendwie Hut auf seinem

System. Das Ganze hat er dann noch irgendwie containerisiert gemacht. Hat er allerdings die Security Option no new privileges gesetzt und Fazit war, er war an der Stelle dann halt nicht gut. Also insofern, ein bisschen vorsichtig mit irgendwelchen Pauschalaussagen letztendlich. Aber fassen wir noch zusammen. Container

Das sind keine virtuellen Maschinen, das sind noch weniger Sandboxen. Sicherheit kann in manchen Szenarien kontenerisiert besser als per Metal sein, muss aber nicht unbedingt. Es gibt sehr viele Möglichkeiten zur Absicherung. Wie gesagt, Problem ist, die Feature wollen genutzt werden, teilweise auch erst aktiviert. Ansonsten, ich denke mal, mit vertrauensvollen Images mein Host sicher konfiguriert und einfach ein bisschen eingegrenzt,

wer irgendwie darauf zugreifen darf und sowas wie gesunder Menscheverstand, fährt man da eigentlich gar nicht so schlecht. Und ansonsten etablierte Prozesse und Verfahren anwenden und nicht, weil alles so leicht ist, irgendwie komplett bewährte Prozesse und Konzepte irgendwie über Bord werfen.

Ja, insofern, weil Wahl ist, ein bisschen Wahlwerbung und ich denke mal, es wäre noch Zeit für Fragen. Ansonsten, noch ein kurzer Werbeblock, wer aus dem südlichen Bereich sein sollte. Wir hatten dieses Jahr das dritte Jahr in Tübingen die Tübix. Ein deutlich kleinerer Linux-Tag als hier.

Trotzdem irgendwie relativ kuschelig und wir werden nächstes Jahr auch wieder einen machen und Details gibt es dann unter Tübixorg, wer mag. Insofern, wer Fragen hat, mich gern löchern. Ich bin ansonsten auch später irgendwie bei einer Bratwurst oder so zu haben.