 deutschen Übersetzung von Hacking Containers und Kubernetes übersetzt von Stefan und Felix. Wir empfangen Thomas, der Kubernetes und Container hackt. Es ist ein bisschen Aufwand, sowas zu hacken, aber es ist auch nur wenig Aufwand, das sicherer zu machen. Willkommen. Gehen wir direkt in die Details. Das bin ich. Ich war mal CTO und bin jetzt Partner bei Endecode. Chief Cloud Wizard heißt nichts, aber das beschreibt eigentlich das, was ich mache. Ich war und bin in der Systemautomation DevOps und Cloud-Umgebung Spezialist zu meiner Geschichte. Ich habe angefangen mit dem Apple 2, um Atari und so weiter und so weiter und bin Linux Nutzer seitdem Linux 095 gegeben hat. Ich bin ziemlich alt und hatte ein bisschen Geschichte. An den Beispielen werdet ihr das wahrscheinlich feststellen und mitbekommen. Ein kleiner Disclaimer. Endecode war Partner bei CoreOS, was von Redhead, was von IBM aufgekauft wurde. Unser Business ist Consulting Training Word Tricks und Audits. Dieser Talk ist nicht über den Kubernetes Code Audit, sondern es geht in diesem Talk um die Nutzersicht, wo man aufpassen muss und wie man das sicher akkremieren kann. Ein bisschen Geschichte. Die Geschichte von Kubernetes. Das Projekt ist sehr schnell gewachsen und mit schnell, meine ich, in 2013 gab es noch nicht wirklich. Es gab das Borgprojekt bei Google und in 2014 haben sie es publiziert und direkt IBM und Redhead sind mit eingestiegen. Wir haben auch ein bisschen getestet, wie es funktioniert. Wir haben unsere erste Kubernetes-Umgebung in 2015, so Sachen wie Grundgesetzartikel, G10 in der Amazon Cloud. Dann kam Helmrout raus, bisschen Training, anfängert zu Kubernetes einführen und ihr seht in der Geschichte das Bergsystem, das Borgsystem. Ihr erinnert euch vielleicht an Seven of Nine in Stadtrick Voyager. Das Seven of Nine ist die Inspiration für die sieben Stäbe von dem Rad von Kubernetes, also der freundliche Borg. Das waren alles seitdem etwas Spieleentwicklungen. In dem letzten Jahr sind viele Leute zu uns gekommen mit kritischeren Anwendungen, zum Beispiel für Stromverteilung und solche Sachen. Mit diesem Talk möchte ich euch aufmuttern, euch das selbst noch mal anzuschauen und da einen Eindruck davon zu machen. Auf diesen ganzen Sachen wird Kubernetes benutzt. Ich habe vergessen die Backends von Auto und es gibt auch Gesichtserkennung in Kubernetes, also Sicherheitsaspekte, die es bei den üblichen Unternehmen dazu gibt. Wer noch nichts von Kubernetes gehört hat, Kubernetes ist der griechische Wort für Steuermann. Es ist 100% Open Source, es ist in Go geschrieben, ihr könnt es ändern, ihr könnt es kompilieren, ihr könnt es installieren. Es ist kein Produkt, es gibt Leute, manche Leute, die Produkte draus machen, aber Kubernetes ist nicht ein Produkt. Kubernetes Managed Angebung und Container, die 10.000 Fußsicht. Auf der linken Seite habt ihr die Lude, die Userinterface, die sich mit der Userinterface auf dem Master Server verbinden, die Sachen, die man speichert, werden in EDCD gespeichert, das ist auch ein verteiltes System, die ganze Konfiguration, alles was Passwörter usw. der Zustand des Clusters ist in EDCD. Es gibt dann noch ein Scheduler usw. der alles dann auf den Notes startet und das sind dann die Cubelets und die kümmern sich dann darum Docker Container oder irgendwelche andere Container, dass es für Kubernetes egal startet. Das ist das, was euch interessieren solltet, also die Userseite, die API und der Container Cluster. Das ist nicht ganz das, was wir machen auf diesem Event und auf Kongressen. Wir schauen uns jetzt DevSecOps an. Mein Hauptsinnachricht ist, dass Kubernetes Teil von der DevSecOps Landschaft ist. DevOps ist tot, aber es gibt halt DevSecOps, noch ein paar andere Apps. Es ist nie wirklich definiert, was da alles drin ist und zusätzlich zu dem üblichen Stack an Sicherheit fügt Kubernetes noch Automation und Audits hinzu. Es gibt keine gute Definition von DevSecOps. Für mich ist es eine Philosophie. Man nimmt DevOps und fügt Sicherheit zu allen Schritten hinzu. Das bedeutet, es geht um Ausbildung, um Erfahrung, um den richtigen Mindset. Wir mussten klare Vorstellungen davon haben, um was es geht und was gehört da alles dazu. Das ist eine typische Karte von verschiedenen Sachen, was Kubernetes unterstützt und eine Reihe von Cloud-Provider brauchen, müssen einige Sachen tun. Das ist eine sehr komplexe Karte und wir müssen mit allen diesen Sachen umgehen. Das ist der Hintergrund. Lass uns technisch werden. Was ist ein Container? Es wird häufig zu einem leichtgewichtigen virtuellen System verglichen. Aus Sicht der Entwicklern sieht es aus wie eine virtuelle Maschine. Man kann in einen Container alles rein installieren. Aus Sicht von Operations, vom Betrieb sieht man, man kann das so machen, aber das passt nicht besonders gut. Man sollte die 12-Faktor-Philosophie verfolgen. Pro Container, ein Prozess, eine Aufgabe, sehr gezielt das einsetzen. Was sind also jetzt Container? Ja, Docker ist ein Container. Container sind eine Möglichkeit, Linux-Prozesse zu isolieren und damit kann man definieren, wie sie isoliert werden, welche Fähigkeiten sie benutzen können dürfen. Bei virtuellen Maschinen sehen wir auf der linken Seite. Es gibt einen Hypervisor, der diese Maschinen, virtuelle Maschinen verwaltet und da drin laufen eigene komplette Betriebssysteme, während bei den Containern ein Linux-Körnel, die eigentlich ein Prozess startet und die sind isoliert und die Kommunikation erfolgt über den einen Linux-Körnel. Und der Körnel stellt auch die Isolierung sicher. Linux-Namespaces sind nicht so bekannt. Das sind die Namespaces, die es im Körnel gibt. Am wichtigsten sind das Wichtigste daran ist, man kann für jeden Prozess festlegen, in welchem Namespace sie laufen sollen. Und man kann das jeweils einzeln festlegen. Man kann also mehrere Prozesse zum Beispiel in einen Netzwerkstecken stecken, aber zum Beispiel in andere Datei-Systeme zu greifen lassen. Sogenannte Capabilities, die Fähigkeiten, die das sind, die 38 Capabilities, die es für 64-Bit gibt und das gibt einem Prozess bestimmte Rechte, zum Beispiel die Netzwerkkonfiguration zu ändern oder raw, also direkt auf Pakete senden und empfangen zu können, am normalen Protokoll-Stack vorbei. Systime um die Zeit des Systems zu verändern. Mit Systime zum Beispiel kann ein Container die Uhrzeit verändern. Es gibt eine ganze Reihe von falschen Informationen. Das BSI versteht offensichtlich Container noch nicht so richtig gut und man hat so eine 50-50 Chance, dass die Informationen da tatsächlich korrekt sind. Und auch der EX-Artikel von Heise ist nicht so wahnsinnig hilfreich. Glaubt nicht unbedingt, was ihr da lesen könnt. Denkt selber nach. So, jetzt geht es um Kubernetes-Pots. Und für Kubernetes ist das vor allen Dingen eine Möglichkeit, dieselbe Netzwerk-Umgebung, den selben Netzwerk-Namespace zu haben. Alle Prozesse in diesem Port teilen sich zum Beispiel die DNS-Konfiguration. Der Localhost ist derselbe für alle diese Prozesse. Tunneling, wenn man es aufsetzt, gehört dazu. Die können aber alle trotzdem unterschiedliche Prozess-IDs und Dateisysteme haben. Hier ist ein Beispiel. Links sehen wir, was da passiert. Ein NGNX-Webserver wird gestartet. Jeder Port hat mindestens einen Container, aber umgekehrt kann ein Port mehrere Container haben. Hier als Standardbeispiel der NGNX-Webserver soll die Möglichkeit haben, auf ein MySQL-Datenbank-Server zuzugreifen. Hier kann man sehen, auf der linken Seite das grüne, das ist der WordPress-Prozess, der auf die Datenbank zugreift, über Localhost. Auf der rechten Seite sehen wir ein Cloud SQL Proxy, der mit zusätzlichen Username und Passworden auf eine verschlüsselte TCP-Proxy-Verbindung aufmacht. Hier ist dann gesichert. Wenn man dieses Produkt von Google nicht verwenden möchte, dann kann man da auch eine Reihe von Open-Source-Alternativen verwenden. Man kann hier natürlich auch seinen eigenen Datenbank-Cluster als Ziel angeben. Das ist ein Anwendungsfall, wo ein Port dabei hilft, die Datenbankverbindung sicherer zu machen als unter normalen Umständen. Secrets, also Geheimnisse, ist eine Funktion von Kubernetes, um Username, Passworder, Apikis, Ähnliches zu managen. Zertifikate, private Schlüssel für genau diese Cloud SQL Connection, das ist eine sehr typische Geschichte, wie man mit Kubernetes so eine Verbindung konfiguriert. Wenn ihr euch das genauer anschauen wollt, dann kiere ein paar Empfehlungen zum Nachlesen. Wenn euch das BSI Zeugs nicht so gut gefällt, startet mal mit der amerikanischen Standardbehörde NIST. Die haben sehr gute Unterlagen erarbeitet, wie man Kubernetes absichern kann. Die Kubernetes-Architektur basiert auf Namespaces und Bindings und Podsecrets, Roles und so weiter und so weiter. Das ganze Blauzeugs sind Objekte in Kubernetes und die können sich mit dem Kubernetes-Server-Account verbinden. Aber das muss von unserem von eurem CloudProvider implementiert sein. Falls ihr das selber macht, müsst ihr das selber implementieren. Dann gibt es die Pod Security Policy. Es ist etwas schwieriger, weil ihr die hardware-Maschine von Sachen, die auf dem Container laufen. Falls ihr Kubernetes komplett falsch konfiguriert, könnt ihr theoretisch auch aus einem Container kompletten Zugriff auf das Host-Betriebssystem kriegen. Hier habe ich ein Beispiel, wie man Zugriff auf Dockersocket bekommt. Was ihr machen solltet, ist, euren eigenen Admission Controller zu implementieren. Die Pod Security Policy ist ein Admission Controller und das kontrolliert, wie ihr Pods auf eurem Kubernetes startet und kann sogar dann die Konfiguration von Pods ändern. Das sind Sachen, die ihr lesen solltet. Falls ihr Deployments anfängt, ich hatte euch ja die Capabilities angezeigt. Kubernetes hat Defaults und Docker insbesondere hat Capabilities, die relativ müh sind. Da würde ich euch empfehlen, die Sachen, die ich euch da aufgeschrieben habe, dann zu setzen. Zum Beispiel diese Defaults, die Docker hat, das ist sehr offen und zu offen. Zum Beispiel Duck Override, das erlaubt einem Nutzer, damit kann Ruth die Leseschreib und Privileg-Sports zu umgehen und Red Hat sagt, das braucht kein Container. Das braucht ihr höchstens, um Privileg-Sports zu benutzen, aber das braucht ihr normalerweise nicht. Es gibt zum Beispiel auch noch so ein paar andere Sachen. Wir müssen auch in den Container reingucken. Zum Beispiel ExactVe, die kann mehr Privileg-Sports im Prozess geben. Es gibt in Linux 3.5.9 Flag, der nun new proofs heißt. Das ExactVe ist eine Dove-Edie und nun new proofs. Da kann man noch bei Kubernetes Ausnahmen geben, aber die Ausnahmen sind auch sehr komisch definiert. Es gibt ein paar Privileges, die dann trotzdem hinzugefügt werden, um dann zum Beispiel SUID Binarys nicht kaputt zu machen usw. Das müsst ihr dann selber überprüfen. Danke Andreas Peters von Spiegel Online, der diesen Fehler gefunden und beschrieben hat. Was passiert mit einem schlecht konfigurierten Cluster? Als jemand noch ein Kubernetes bis 1.6 hat, benutzt es nicht in Production. Hier könnt ihr aus der Busybox raus ein Docker-Prozess starten, klickt dann Zugriff auf den Docker-Socket und könnt dann die Docker-Binary aus dem Container raus, was schön ist, um dann Container innerhalb von Container bauen können. Aber sicherheitstechnisch ist es relativ schlimm und es sollte ausgeschaltet sein. Wir haben auch noch über Komplexität gesprochen. Wir sind uns alle einig, dass Komplexität, was nicht der Sicherheit zuträgt, was er auch noch sagt, ist, dass wir Komplexität lieben. Wir müssen es also besprechen. Das ist allerdings eine philosophische oder religiöse Debatte meiner Meinung nach, aber es ist keine technische Hürde. Hier ist eine Netzwerksicht. Ich habe euch gewarnt, da ist Komplexität trenn. Das Blaue ist noch mal Kubernetes. Das Beispiel ist hier zum Beispiel wieder, dass ihr ein Ingress aufsetzt, mit dem ihr dann von außen das Kubernetes beeinflussen könnt. Das kann dann zum Beispiel an einen regionalen oder globalen Notbalancer angeschlossen werden und damit könnt ihr globale Rollen an euer Cluster übergeben. Es gibt also ein Zertifikat an Google Cloud, kriegt dann ein Zertifikat zurück und Google wird dann den Traffic in eure Sache injizieren. Da kriegt ihr dann 40 Gigabit pro Sekunde Anbindung ans Internet, aber das ist sehr komplex. Und ihr müsst dann, um das benutzen zu können, Custom Controller dann entwickeln, die das dann für euch machen würde. Die hellblauen Sachen kommen aus dem Linux Kernel mit zum Beispiel BGP Rollen und so weiter. Das müsstet ihr dann alles auch selbst machen. Und darunter ist dann noch die Hardware, die dann durch ihr Kubernetes konfiguriert ist und solche Sachen. Das ist dann der Hauptteil des Netzwerks, des Netzwerksystems. Was wir machen, Kunden kommen zu uns und wir sagen, wir brauchen mehr Sicherheit. Und wir können, wir bieten dann an Audits von deren Kubernetes Cluster zu machen und was die Bisser machen könnten, was besser gemacht werden kann und wie sie Sicherheit betrachten müssen. Was wir gefunden haben, ist, dass es meistens dann in diese verschiedenen Kategorien geht. Storage zum Beispiel ist nicht ein Teil von Kubernetes, aber da gibt es immer dann Sicherheitsprobleme, zum Beispiel verteilte Datenbanken und Storage. Das Beste wäre, sich den Tweet Talk anzuschauen, der auf der Foehrings-Lite war und versucht zu verstehen, versucht das Captheorem zu verstehen. Ihr könnt nur zwei von den drei Sachen im Captheorem zu kriegen. Und Replikation ist schwierig, selbst in dem Einfachsten Sinn. Das ist schwierig zu implementieren. Danach haben wir die Images und die Docker Images. Und die Code von Quellen, die man nicht kennt, als Rout auf dem Kubernetes Cluster laufen zu lassen, ist eine schlechte Idee. Eine sehr, sehr schlechte Idee. Cube CTL zum Beispiel kann gehyject werden. Das wäre eine 30-minutige Aufgabe sein, um das zu gehen. Bei den Registries, da hat es viel auch infizierten Code gegeben und wir hätten Microsoft nie verzeihen für diesen ganzen Krämpel. Ungefähr zwei Drittel oder dreiviertel der Container hatten Mittel oder hohe Sicherheitsprobleme in 2015. Das könnt ihr dann lokal implementieren, da verschiedene Checks nach. Es ist leider in 2018 nicht besser geworden und ich würde nichts darauf wetten, dass es inzwischen besser geworden ist. Checkt eure Images, bevor ihr sie benutzt. Danach geht es um den Cluster Setup. Ein Cluster zu installieren ist relativ einfach, aber es zu updaten ist schwierig. Da braucht ihr mindestens fünf Leute für und automatisiert so viel wie möglich. Am besten auch auf der letzten Version von Kubernetes Deployen. Aber Kubernetes geht immer mehr in die Sicherheit rein. Es könnte sein, dass ihr Container habt, die nicht auf dem letzten Kubernetes laufen werden. Dann geht es um die Sicherheit von Pots, Schaltet SO-Lenux oder AppArmor nicht raus, benutzt brauchbare Defaults und hier gibt es ein Beispiel, wie ihr nach Privileges und Capabilities checken könnt. Es gibt auch nichts wie ein Security Context, das grüne ist ein Gute und da kann man es dann checken. Checkt die Runtimes. Aktuell ist noch Docker der Default, es wird auch Cryo geben, RKT ist outdated, ihr könnt auch mit Hypervisor und mit Google Cloud dann gehostete Sachen haben. Und auf der G-Visor wird auch tatsächlich dann die meisten Sachen, die problematisch sind, spokiert. In der Zukunft wirds die Runtime Class auch konfigurierbar machen. Das ist eine restriktive Policy, am besten sowas Deployen. Es wird auch alles verbieten und nur die Sachen, die ihr braucht, zum Beispiel sehr höchstsichere Volumes erlauben, Blockkompetent, Nuss-IPC usw. Ihr könnt auch Auditierungslocks hinzufügen, wenn ihr zum Beispiel DevSecOps in der Medizin einsetzen wollt. Dann macht es Sinn, alle Kubernetes-Files im Git zu haben, die Secrets in einem eigenen Branch, der geschützt ist. Damit kann man immer sehen, wann etwas kann man sehen, was sich verändert, wann irgendjemand ein Container startet. In Google wird es entsprechend in ein eigenes System gelockt und ein Auditor kann jetzt über entsprechende Abfragen alle diese Events nachvollziehen. Wenn euch Google nicht gefährdet, kann man das auch mit Elasticsearch machen. Und Elasticsearch hat auch ein entsprechendes, rechtebasiertes Rollensystem, mit dem man genau diese Events auch erzeugen kann. Das nächste ist das Netzwerk, Netzwerk-Policies, was man hier sehen kann. Man kann Kali-Co zu Kubernetes zufügen. Das ist die Standard-Netzwerk-Schicht. Jedes Mal, wenn sich etwas in der Netzwerk-Konfiguration endet, dann wird das C&I, das Container-Network-Interface, aufgerufen und irgendwelche Änderungen, Routing-Tabellen oder BGP-Änderungen werden auch gelockt. Alle Policy-Entscheidungen, wie zum Beispiel die Firewall-Regeln, Labels für Verbindungen, Namespaces, Ports und Regeln wie zum Beispiel, dass die Datenbank nur aus dem Frontend erreichbar sein soll. Das ist Standard-IP-Tables-Konfiguration. Das nächste richtig heiße Ding sind Service-Meshes und Istio. Es ist eine Einklick-Lösung für Kubernetes, mit der man eine Mischung aus Public und Private Cloud machen kann, also irgendwas in der Cloud und bei sich auf eigenen Rechnern. Das wird Teil von OpenShift 4 werden. Im Moment wird es vor allen Dingen von Google, IBM und Red Hat ausprobiert und vorbereitet. Es sollte sehr sicher sein. Lass uns da ein bisschen genauer reinschauen. Alle Buzzwords, was man so gerne hören möchte, was sie dafür benutzen, sind die sogenannten Sidecars, die Beiwagen. Und da gibt es also einen Container innerhalb des Ports, der quasi als Proxy fungiert und mit einem Inlet-Container werden zu Beginn des Staats des Ports die Firewall-Regeln verändert, die IP-Tables-Regeln. Und dafür braucht dieser Container natürlich die Net-Admin-Rechte, was nicht so gern erwähnt wird. Und dann gibt es noch ganz viele weitere Geschichten wie Citadel. Das ist ein Bild eines Service-Messages und die Microservices werden durch die Sidecars unterstützt und die Microservices können also den Regeln der Sidecars normalerweise nicht entkommen. Hier ist zum Beispiel eine Möglichkeit, wie ein Service dann doch die Regeln umgehen kann. Und man kann es einfach umgehen, indem man die IP-Tables aus einem anderen Container heraus einfach wieder so ändert, wie man sie gerne haben möchte. Und man benutzt den Istio-Container, um die Beschränkungen einfach wieder zu entfernen. Und damit ist dann die gesamte Netzwerksicherheit komplett aufgelöst. Man hat also Networkkonfiguration, Netzwerksicherheit hinzugefügt, aber Mandantenfähigkeit ist abgeschafft, denn jeder Mandant kann nun wiederum diese Netzwerksicherheit auflösen. Und man kann das lösen, indem man entsprechende Sicherheitsregeln definiert. Im Allgemeinen hat diesen Exploit im März veröffentlicht. Und ich war auch nicht der Erste, der auf dieses Problem gestoßen ist. Und das ist jetzt effektiv so ein Scriptkiddy-Zugang Istio 1.2 wird das Container-Network-Interface diese Funktionen übernehmen und damit ist dann das aus dem User-Space heraus nicht mehr so einfach wirklich. Und man kann das dann also nicht mehr vom Microsoft aus kontrollieren. 1.2 ist im Prinzip fertig, ist aber noch nicht ausgerollt. Der Standard ist immer noch der Sidecar mit der entsprechenden Angriffsmöglichkeit. Achtet also darauf, wenn ihr Istio für jetzt im Moment verwendet. Aber im Moment sind das noch sehr wenige, auch wenn das jetzt scheinbar gerade am Zunehmen begriffen ist. Zusammenfassung. Sehr lange Zusammenfassung. Es macht sehr viel Spaß mit Kubernetes zu arbeiten. Es erinnert mich daran, wie das so war mit Unix zu arbeiten in den 90ern. Wenn man Spaß an System Engineering hat, man stellt die Marketingfolien in Frage und man kann sehr schnell Probleme finden und die relativ einfach ausnutzen. DevSecOps ist eine gute Idee, aber vergesst Sec die Sicherheit dabei nicht. Wenn ihr etwas genauer in die Details dieses Systeme einsteigt, dann werdet ihr auf jeden Fall Probleme finden. Und das können Doktor Probleme und nicht notwendigerweise Probleme von Kubernetes, sondern tatsächlich von Docker beziehungsweise dem Capability System vom Linux. Ihr werdet jede Menge Bussballs finden und konzentriert euch auf ein Sicherheitsaspekt und dann findet jemand in einem anderen Aspekt ein Sicherheitsproblem und dann ist eure ganze Arbeit vertraut im Code nicht. Vertraut niemanden. Die Community ist sehr aufgeschlossen, Problemberichten gegenüber, also mit Responsible Disclosure kommt man sehr weit. Nutzt es gerne? Benutzt es verantwortungsbewusst? Schaut euch die Sicherheit an. Wenn ihr Fragen habt, dann versuche ich über allen Wolken zu bleiben. Werden Workshop geben um drei in der C-Base und jetzt zu den Fragen. Was ist der Sicherheitsimpact speziell des Sidecars? Man kann es ausschalten, indem man den NetAdmin Container zusätzlich gebroit. Man muss seinen Containern vertrauen können. Wenn man es richtig gemacht hat, dann hätte man einen Admission Controller, der diese NetAdmin-Kapability nicht zur Verfügung stellen würde. Es ist ein interner Angriff, aber man kann die Einschränkungen einfach wieder entfernen und damit ist man dann in Wirklichkeit nicht sicher. Wenn du möchtest, kann ich dir den Workshop direkt zeigen. Die eigentliche Anwendung läuft aber noch, und die läuft auch unprivilegiert. Ja, genau, die läuft unprivilegiert. Die Applikation kann damit dann alle Einschränkungen umgehen, also kann nach Hause telefonieren oder ähnliches. Aber wenn man Projektspezifische Permissions einstellt, die braucht man nicht. Wenn man den Cluster aufsetzt mit Listeo, dann wird das injiziert und die Regeln können dann aber wieder entfernen. Vielen Dank für den tollen Vortrag. Hast du Cube Let Me In gesehen? Wir können da später noch mal drüber reden. Es gibt eine ganze Reihe von Sicherheitslücken, die für eigentlich alle kuperdetes Anbieter gelten. Ja, das ist wahrscheinlich möglich. Wenn man alles zusammennimmt, dann hat man eine sehr schöne Sammlung von Exploits. Ja, ich würde mich freuen, wenn wir da gemeinsam noch mal drauf gucken können. Bitte langsam versprechen. Vielen Dank für den Vortrag. Das war sehr interessant. Kann man Helm, den Package-Mender etwas sicherer machen? Was ich empfehlen würde, ist Helm auf jeden Fall auf bestimmte Namespaces einzuschränken. Mit minus minus tiller Namespace kann man den Namespace auf einen bestimmten Namespace einschränken, auch wenn tiller jetzt gerade aus Helm entfernt wird. Man kann Helm also so installieren und starten, dass es nur auf einen Namespace wirken kann. Im Moment hat es vollen Systemzugriff und man kann über Helm beliebige Änderungen vornehmen. Noch Fragen aus dem Internet. Vielen Dank. Ihr habt die Übersetzung gehört von