Announcement: there is an English version of this forum on Wir hatten mal wieder die Pentester im Haus und es gab mal wieder gravierende Probleme. Dieses Mal mitten in unserer Kubernetes Produktivumgebung. Als CISO bin ich zwar für die Sicherheit dieser Umgebung verantwortlich, habe aber praktisch nichts damit zu tun. Unsere Entwickler betreiben das Cluster als eine Art autonome Zone, in der Autoritäten wie ich grundsätzlich nichts zu sagen haben. Aber was war passiert? Unsere Pentester haben sich einen Account auf unserer öffentlichen SaaS Plattform geklickt. Schnell haben sie einen angreifbaren Service gefunden, bei dem sie über eine Local File Inclusion Informationen zur Ausnutzung einer Remote Code Execution sammeln konnten. Nach Auslesen der Umgebungsvariablen hatten sie Vollzugriff auf unsere Produktivdatenbank. Außerdem fanden sie eine ganze Reihe weiterer verwundbarer Container aus ganz anderen Namespaces. Die ausgenutzten Sicherheitslücken sind uralter Mist, fast ein Jahr alt. Sie existieren in Drittanbieterimages, die unsere feinen Herrn Entwickler scheinbar nie gepatcht haben. Wir aus der IT-Security kriegen keinen Blick in das Cluster. Auch Firewalls sind für unsere Entwickler offenbar ein Fremdwort. Hier wird nur ohne Sinn und Verstand schnell irgendein Müll zusammengeklickt und selbst jetzt keine Konsequenzen gezogen. Für die Erstellung von VMs haben wir einen Genehmigungsprozess, der über die IT Sicherheit läuft. Da achten wir dann auf die Einordnung in Netzsegmente und Monitoren die Maschinen auch soweit möglich auf Patches und Verfügbarkeit. Außerdem verwalten wir die Firewalls und Virenscanner zentral. Und im Kubernetes Cluster? Da wird wild-west gespielt und den Entwicklern das Feld überlassen. Das darf doch einfach nicht wahr sein? Gibt es Verfahren zur Etablierung von Freigabeprozessen und Überwachung der Sicherheit in so einem Wildwest-Cluster oder ist das überhaupt nicht vorgesehen?
Als CISO solltest Du die Befugnisse haben, entsprechende Guidelines und Kriterien zu erlassen, nach denen sich die Entwickler zu richten haben. Im weitestens Sinne ist es deine Unterlassenschaft, dass die wild-west-entwickler so was dürfen. Aber "wir monitoren dann die VMs" klingt halt auch nach ganz verstaubter ITIL-Prozessmanier. Aber mach dir nichts draus. Deine Situation ist alltäglich, und nur zu viele Entwickler haben das Gefühl sie seien fähig, Security, Operations, Continuity, Lifecycle, unter einen Hut zu bringen. Aber die wenigsten haben Plan davon, die meisten sind ja schon überfordert den hauseigenen Identity Provider einzubinden.
:
Bearbeitet durch User
CISO schrieb: > Wir hatten mal wieder die Pentester im Haus und es gab mal wieder > gravierende Probleme. Dieses Mal mitten in unserer Kubernetes > Produktivumgebung. Als CISO bin ich zwar für die Sicherheit dieser > Umgebung verantwortlich, habe aber praktisch nichts damit zu tun. Hans, VmFreak, <etliche andere Nicks>, trollst wieder mit Deinem Kreuzzug gegen Docker, Kubernetes, und alles andere, das Dich überfordert? Was ist es diesmal, wieder Dein Monatszyklus, Deine Frustration oder schon wieder ein schlimmer Anfall von Langeweile?
Rubble C. schrieb: > Als CISO solltest Du die Befugnisse haben, entsprechende Guidelines und > Kriterien zu erlassen, nach denen sich die Entwickler zu richten haben. Ja, die habe ich, aber du weißt ja scheinbar selbst wie das ist. Über mehrere Abteilungen hinweg ist es mit der Durchsetzung dann nicht mehr ganz so weit her und ein zäher Prozess. Rubble C. schrieb: > Im weitestens Sinne ist es deine Unterlassenschaft, dass die > wild-west-entwickler so was dürfen. Aber "wir monitoren dann die VMs" > klingt halt auch nach ganz verstaubter ITIL-Prozessmanier. Was schlägst du vor? Das allein ist natürlich nicht unser Sicherheitskonzept, aber doch ein valider Teil davon. Ein T. schrieb: > Hans, VmFreak, <etliche andere Nicks>, trollst wieder mit Deinem > Kreuzzug gegen Docker, Kubernetes, und alles andere, das Dich > überfordert? Was ist es diesmal, wieder Dein Monatszyklus, Deine > Frustration oder schon wieder ein schlimmer Anfall von Langeweile? Hä?
CISO schrieb: > Rubble C. schrieb: >> Als CISO solltest Du die Befugnisse haben, entsprechende Guidelines und >> Kriterien zu erlassen, nach denen sich die Entwickler zu richten haben. > > Ja, die habe ich, aber du weißt ja scheinbar selbst wie das ist. Über > mehrere Abteilungen hinweg ist es mit der Durchsetzung dann nicht mehr > ganz so weit her und ein zäher Prozess. Wenn ihr so inkonsequent seid: Selber schuld. Regeln durchsetzen war noch nie einfach.
Ganz Einfach: Laut verkünden "Wer nochmal mit Kubernetes oder ähnlichen Point&Click Spielereien rummacht anstatt ordentliche Arbeit zu leisten bekommt die Kündigung" Sowas zieht Immer.
Das Problem ist häufig, dass die IT in den großen Firmen der Technologie um viele Jahre hinterherrennt. Endlose approval Prozesse, schlecht dokumentiert, viel zu aufgeblasen, von jedem unterschiedlich verstanden und ausgeführt, unflexible VMs, für jeden Dienst eine eigene, kein deployment unter nem Monat oder länger, 3rd party admins, die keinen Plan von nix haben... Das ist einfach unglaublich ätzend und innovationsfeindlich. Ich verstehe, dass die Entwickler versuchen, Alternativen zu finden, um einfach nicht abgehängt zu werden. Denn dafür werden Entwickler nämlich bezahlt. Innovation und verkaufbare Produkte. Kontextwechsel hilft in solchen Fällen ab und zu. Und je nach Firma ist die IT im Prinzip ein Dienstleister fürs engineering und production. Wollen aber viele natürlich nicht so sehen ;) und ja, ich verstehe, dass IT für die Sicherheit zuständig ist bzw sein sollte. Am Ende geht es nur, wenn die Abteilungen zusammen und nicht gegeneinander arbeiten. Heißt: nicht "die scheiß Entwickler reißen mir hier Löcher in die FW", sondern "wie können wir moderne Technologien etablieren und gleichzeitig Sicherheit bieten"? Und die Möglichkeiten wird's ja wohl geben... Dafür müssen aber die Ziele und KPIs entsprechend definiert sein. Ob das bei euch so ist weiß ich natürlich nicht, viel zu häufig läuft es aber genau so leider.
Erstmal: der Pentest ist doch super gelaufen! Es wurden mehrere tatsächliche Schwachstellen und Schwachstellen in den Prozessen gefunden. Mit Glück sogar noch bevor ein böser Hacker die gefunden hat. Ihr habt in einen vermutlich selbst entwickelten Service eine File Inclusion-Schwachstelle. Das ist ein Programmierfehler der natürlich behoben werden muss. Wer eine File Inclusion oder Directory Traversal Schwachstelle hat hat sicher mehrere davon, vermutlich auch (SQL-)Injection-Schwachstellen. Damit so was nicht öfter passiert braucht ihr Coding Guidelines und Security-Schulungen der Entwickler. Ein Review, zumindest der exponierten Dienste, ist danach ebenfalls angebracht. Dann die veraltete Software, oft nicht mal selbst verbaut sondern in Drittanbieter-Images und Bibliotheken. Da können die eigenen Entwickler nicht mal immer was dafür, es ist inzwischen halt so, dass ein Großteil der Probleme in Abhängigkeiten oder gar transitiven Abhängigkeiten vergraben liegt. Ebenso erfolgen heute viele Angriffe über diesen Weg: als Supply-Chain-Attacks. Sinnvoll wäre natürlich ein vollständiges Softwareinventar, also eine Zusammenstellung aller verwendeten Softwareversionen. Dann kann man zielgerichteter reagieren oder weiß bei neuen Schwachstellen wie in log4j überhaupt erst, ob bzw. wo man betroffen ist. Das Inventar manuell zu erstellen ist kaum machbar. Du brauchst deshalb automatisierte Schwachstellenscanner, die alle Umgebungen (development, test, production) regelmäßig durchscannen. Nicht monatlich, sondern täglich. Gefundene Schwachstellen müssen zeitnah bewertet und ggf. behandelt werden. Es bietet sich an, diese Response-Prozesse ähnlich wie das Incident-Management, also die Reaktion, wenn tatsächlich mal etwas passiert ist, aufzubauen. Wenn die Entwickler dich nicht auf dem Produktivsystem haben wollen brauchst du ein äquivalentes System in Test und die Ops müssen in der Lage sein, prod komplett durchzudeployen. Erprobt und ohne dass da irgendwelche Altlasten stehen bleiben. Um die Aufwände rechtfertigen zu können brauchst du Bedrohungsanalysen mit einer Bewertung der Risiken. Ein Security-Vorfall kann das ganze Unternehmen in wenigen Tagen ruinieren. Es ist deine Aufgabe, dieses Risiko zu ermitteln, der Geschäftsführung transparent zu machen und durch Maßnahmen zu begrenzen. Die Bedrohungsanalyse ist auch ein guter Ausgangspunkt, um daraus eine Netzwerkzonierung und Firewall-Konzepte abzuleiten.
60/40 schrieb: > Ganz Einfach: > > Laut verkünden "Wer nochmal mit Kubernetes oder ähnlichen Point&Click > Spielereien rummacht anstatt ordentliche Arbeit zu leisten bekommt die > Kündigung" Sowas zieht Immer. Ich glaube du hast das Problem des TO nicht erfasst. Er trägt Verantwortung, ich jedoch nicht entsprechend Weisungs-befugt. So etwas habe ich selbst in einem Konzern aus Sicht des Entwicklers beobachtet. Für mich waren die Prioritäten immer: 1) schnell und billig 2) dokumentieren 3) security Die armen Security Kollegen haben sich ständig zu Recht beklagt, dass ihre Anforderungen nicht umgesetzt wurden. Hat nur keinen Interessiert, weil diese Leute weder zur Projektleitung, noch zur Personalführung gehörten und auch nicht mehr Budget hatten als für ihr eigenes Gehalt und ihre Werkzeuge. Es wurde immer fleißig getestet, doch selten mit Konsequenzen. Wo ich derzeit arbeite sind Betriebler und Security Experten die selben Personen. Das klappt, denn wenn dort einer sagt "das nehme ich so nicht in Betrieb", dann nimmt er es nicht in Betrieb. Punkt. Bei 80% der Security Lücken die wir Entwickler beheben, sind wir ganz sicher, dass sie in unserem Setup irrelevant oder harmlos (nicht ausnutzbar) sind. Aber wir beheben sie trotzdem, denn für lange Diskussionen ist keine Zeit. Wie Tilo schon schrieb: So ein Audit muss täglich laufen und dann zackig behoben werden. Harmlose Lücken zu behebn ist meist schneller und billiger, als darüber zu diskutieren - wenn man den entsprechenden Prozess bereits etabliert hat.
:
Bearbeitet durch User
Tilo R. schrieb: > Ihr habt in einen vermutlich selbst entwickelten Service eine File > Inclusion-Schwachstelle. Das ist ein Programmierfehler der natürlich > behoben werden muss. Allerdings hat das auch nichts mit Docker oder Kubernetes zu tun.
Ein T. schrieb: > Allerdings hat das auch nichts mit Docker oder Kubernetes zu tun. Wenn man von älteren Strukturen mit virtuellen Maschinen auf Kubernetes wechselt, ploppen da schnell eine Menge neue Security-Anforderungen an die Anwendung auf, die früher nicht eingeplant waren. Ich höre auch immer wieder den Spruch "Das kann man doch einfach in die Cloud heben". Und dann gucken alle doof, wenn das Programm nicht sämtliche Kommunikationen mit Zertifikaten absichern kann. "Ich dachte das sei längst Standard", heißt es dann. Ja schon, aber nicht vor 12 Jahren als dieses Produkt designed wurde.
Stefan F. schrieb: > Wenn man von älteren Strukturen mit virtuellen Maschinen auf Kubernetes > wechselt, ploppen da schnell eine Menge neue Security-Anforderungen an > die Anwendung auf, die früher nicht eingeplant waren. Da fallen mir jetzt nicht so viele ein, welche meinst Du denn? > Ich höre auch immer wieder den Spruch "Das kann man doch einfach in die > Cloud heben". Und dann gucken alle doof, wenn das Programm nicht > sämtliche Kommunikationen mit Zertifikaten absichern kann. "Ich dachte > das sei längst Standard", heißt es dann. Ja schon, aber nicht vor 12 > Jahren als dieses Produkt designed wurde. Im Enterprise-Umfeld war das auch vor zwanzig Jahren schon Standard, würde ich sagen. Außerdem kann man dem Thema erstmal genau so begegnen, wie man das früher mit den VMs gemacht hat... nicht schön, aber möglich. ;-) Edit: abgesehen davon hat eine File Inclusion nichts mit Kubernetes oder Docker zu tun, sondern kann genauso auf BM oder in einer VM passieren.
:
Bearbeitet durch User
Ein T. schrieb: > Im Enterprise-Umfeld war das auch vor zwanzig Jahren schon Standard, > würde ich sagen. Nö. Nichtmal bei Google. Da ist auch erst mit den Snowden-Leaks rausgekommen, dass die Kommunikation aller Services nach der https-terminierung unverschlüsselt war. Erst danach hat Google angefangen, auch die internen Verbindungen zu sichern, damit die NSA nicht mehr unbemerkt mitlauschen kann.
Ein T. schrieb: > Da fallen mir jetzt nicht so viele ein, welche meinst Du denn? Ich hab ein Beispiel genannt. Ich habe gar keine Lust weitere zu nennen, weil hier sowieso jedes einzeln von irgendwem "widerlegt" wird. Du hast selbst damit angefangen. Auf dein Argument will ich auch gar nicht weiter eingehen, denn jeder hat andere Bedürfnisse und Erfahrungen. Jeder kann für sich Recht haben.
:
Bearbeitet durch User
Εrnst B. schrieb: > Ein T. schrieb: >> Im Enterprise-Umfeld war das auch vor zwanzig Jahren schon Standard, >> würde ich sagen. > > Nö. Nichtmal bei Google. Vor zwanzig Jahren war Google noch eine unbedeutende kleine Klitsche. Abgesehen davon kommen wir vom Thema ab, insofern: was möchtest Du mir sagen? Daß File Inclusion-Sicherheitslücken nur unter Docker und / oder Kubernetes vorkommen? Daß sie dort verstärkt vorkommen? Daß sie sonstwie eine Spezialität von Kubernetes oder Docker sind, daß sie dort besonders gefährlich sind, oder...?
Ein T. schrieb: > was möchtest Du mir > sagen? Das es 2013, damals war Google gewiss keine "unbedeutende kleine Klitsche" mehr, bei denen auch noch nicht Usus war, interne Dienste verschlüsselt & mit Zertifikaten gesichert untereinander kommunizieren zu lassen. Und 2013 liegt weniger als 20 Jahre zurück. Insofern bezweifle ich deine Behauptung, dass das vor zwanzig Jahren schon absolut üblicher Standard gewesen sei.
Stefan F. schrieb: > Ich hab ein Beispiel genannt. Ich habe gar keine Lust weitere zu nennen, > weil hier sowieso jedes einzeln von irgendwem "widerlegt" wird. Schade. Dann werde ich dabei bleiben müssen, daß die Sicherheitsaspekte bei Docker, Kubernetes & Co. zwar etwas anders, aber keineswegs neu sind -- was viele Leute allerdings intellektuell sehr herauszufordern scheint. Das sehen wir ja an diesem Thread: obwohl File Inclusion-Fehler altbekannt sind und nicht das Geringste mit Docker und / oder Kubernetes zu tun haben, rantet der TO ausweislich des von ihm gewählten Subject gegen diese. So ein Quatsch, File Inclusion hat überhaupt gar nichts mit Docker oder Kubernetes zu tun, denn das gibt es ganz genauso auch auf blankem Blech und virtuellen Maschinen. Dort kann das daraus resultierende Problem bisweilen sogar noch viel größer sein als unter Docker oder Kubernetes, denn in Blechen und VMs liegen nicht nur auf die Kernfunktionalitäten begrenzte Container, sondern komplette Betriebssysteme mit viel mehr sensiblen Informationen.
SPortsfreund! Dann lass dir mal von deim Chef deutlich erklären welche Abteilung das Geld reinholt und welche Abteilung den ganzen langen Tag nur Kohle kostet und keinen Fifferling einbringt! Siehste! Die Entwickler produzieren verkaufbare Dinge. Du bist nur der Fiffi der Geld kostet und auch noch einen auf vollgejammerte Hose macht. Mach dir Wochenende und sauf dich voll. Mehr bleibt dir nicht. Die Entwicker wollen mit so einem sicher nicht saufen gehen.
CISO schrieb: > Unsere > Entwickler betreiben das Cluster als eine Art autonome Zone, in der > Autoritäten wie ich grundsätzlich nichts zu sagen haben. CISO schrieb: > Aber was war passiert? Unsere Pentester haben sich einen Account auf > unserer öffentlichen SaaS Plattform geklickt. Schnell haben sie einen > angreifbaren Service gefunden, bei dem sie über eine Local File > Inclusion Informationen zur Ausnutzung einer Remote Code Execution > sammeln konnten. Schieb das entsprechende Risiko in die Abteilung wo die Entwickler sitzen.
Ein T. schrieb: > Stefan F. schrieb: >> Ich hab ein Beispiel genannt. Ich habe gar keine Lust weitere zu nennen, >> weil hier sowieso jedes einzeln von irgendwem "widerlegt" wird. > > Schade. Dann werde ich dabei bleiben müssen, daß die Sicherheitsaspekte > bei Docker, Kubernetes & Co. zwar etwas anders, aber keineswegs neu sind > -- was viele Leute allerdings intellektuell sehr herauszufordern > scheint. > Dann zeig mir doch mal Wege auf wie ich das angehen kann. Bin für Vorschläge offen.
Benedikt L. schrieb: > SPortsfreund! > > Dann lass dir mal von deim Chef deutlich erklären welche Abteilung das > Geld reinholt und welche Abteilung den ganzen langen Tag nur Kohle > kostet und keinen Fifferling einbringt! Warum schafft man sie dann nicht ab? Oh, die braucht man ja um Kohle zu verdienen...
CISO schrieb: > Ein T. schrieb: > >> Stefan F. schrieb: >>> Ich hab ein Beispiel genannt. Ich habe gar keine Lust weitere zu nennen, >>> weil hier sowieso jedes einzeln von irgendwem "widerlegt" wird. >> >> Schade. Dann werde ich dabei bleiben müssen, daß die Sicherheitsaspekte >> bei Docker, Kubernetes & Co. zwar etwas anders, aber keineswegs neu sind >> -- was viele Leute allerdings intellektuell sehr herauszufordern >> scheint. > > Dann zeig mir doch mal Wege auf wie ich das angehen kann. Bin für > Vorschläge offen. Nach konstruktiven Vorschlägen brauchst du den nicht zu fragen. Der Typ ist nur ein Schaumschläger.
CISO schrieb: > Dann zeig mir doch mal Wege auf wie ich das angehen kann. Bin für > Vorschläge offen. Du hast ein grundsätzliches Problem: entweder werden Deine Funktion, Deine Person oder beides in dem Unternehmen nicht so richtig ernst genommen und deswegen übergangen und ignoriert. Du hast also kein technisches Problem, sondern ein soziales: nämlich eine Kultur, in der wichtige Aufgaben nicht erfüllt und wichtige Funktionen oder / und ihre Funktonsträger ignoriert werden. Das wirst Du ändern müssen. Wenn Du jetzt schon übergangen wirst, ist das aber schwierig. Zeit, Dir Unterstützer und Verbündete zu suchen. Der offenbar verheerende Pentest ist eine gute Gelegenheit, das formell eskalieren. Formell heißt: nicht per E-Mail, sondern klassisch auf Papier, mindestens an Vorstand, Corporate Security und Compliance, zudem idealerweise an die C[A-Z]Os. Anhand des Verlaufs und der Ergebnisse dieser Eskalation siehst Du dann schnell, ob Du nur so ein "nice-to-have"-CISO fürs Marketing sein, oder Deine Funktion wirksam ausfüllen sollst.
Helmut schrieb: > CISO schrieb: > >> Dann zeig mir doch mal Wege auf wie ich das angehen kann. Bin für >> Vorschläge offen. > > Nach konstruktiven Vorschlägen brauchst du den nicht zu fragen. Der Typ > ist nur ein Schaumschläger. Stimmt
CISO schrieb: > Helmut schrieb: >> Nach konstruktiven Vorschlägen brauchst du den nicht zu fragen. Der Typ >> ist nur ein Schaumschläger. > > Stimmt Also doch wieder der Hansel. ;-)
Ein T. schrieb: > CISO schrieb: > >> Helmut schrieb: >> >>> Nach konstruktiven Vorschlägen brauchst du den nicht zu fragen. Der Typ >>> ist nur ein Schaumschläger. >> >> Stimmt > > Also doch wieder der Hansel. ;-) Aha. Glaube du hast dich einfach selbst disqualifiziert.
CISO schrieb: > Aha. Glaube du hast dich einfach selbst disqualifiziert. Aber um das nochmal zu konkretisieren: Ich kann organisatorisch so viele Regeln wie ich will erlassen. Wenn niemand den Überblick über die Versionsstände und Leichendeployments im Cluster hat, dann hat niemand den Überblick. Und an der Stelle will ich ansetzen und die Entwickler unterstützen, nicht knechten. Hier versteht das offenbar keiner. Entweder sind hier Entwickler unterwegs, die ihren Hass auf das Feinbild der Sicherheitsabteilung präsentieren oder die Jubel-Trubel-Heiterkeit Sicherheitsleute, die glauben man könne alle Probleme mit organisatorischen Maßnahmen lösen und dieses Feindbild gleichzeitig schüren. Und zu allem Überfluss ein_typ, der meint mir meinen Job erklären zu müssen.
Stefan F. schrieb: > wenn das Programm nicht sämtliche Kommunikationen mit Zertifikaten absichern kann. Ist doch kein Problem. Gibt ja zeugs wie z.B. stunnel usw. Ich habe auch mal noch das hier gemacht: https://github.com/Daniel-Abrecht/mitm-tools Ist zzar nicht für diesen Fall entwickelt worden, aber sollte trotzdem gehen, die einzelnen Progrämmchen lassen sich alle als transparente Proxies nutzen, und kann man vielseitig kombinieren.
🐧 DPA 🐧 schrieb: > Ist doch kein Problem. Gibt ja zeugs wie z.B. stunnel Ist kein Problem, wenn der Kunde das so akzeptiert. Wenn ...
Lustigerweise habe ich mich gerade heute auch mit einem Kollegen über
sowas unterhalten.
Dabei war es eigentlich garnicht mal Docker, sondern es fing damit an,
dass wir uns über einen Manager für Python-Environments ("pipenv")
unterhielten.
Er ist der Meinung dass (pipenv) ist der optimale Weg, um sich eine
schöne stabile Pythonumgebung für die Entwicklung als auch Laufzeit zu
schaffen, unabhängig vom OS. Mein Einwand war, wie man denn - ggfs.
sicherheitsrelevante - Updates dann managed, wenn es jede Menge
individuelle Python-Envs jeweils mit eigenen lokalen Paketen gibt, die
munter mehr oder weniger eingefroren werden um eine "stabile" Umgebung
zu haben, und nicht vom normalen Patchprozess für das OS erfasst werden.
Schlussendlich kamen wir dann dazu, dass man eigentlich Container bauen
müsste, nur die Frage wer dass dann am Ende alles managen soll (Updates
aller verwendeten Komponenten im Auge behalten, Container entsprechend
pflegen etc.) konnte er auch nicht wirklich beantworten.
Manchmal frage ich mich dann, ob das alles noch sinnvoll handhabbar ist.
Oder ob man sich nicht mehr Probleme einfängt als löst durch die immer
weitere Segmentierung einer Lösung in eine unüberschaubare Anzahl an/von
extern eingebundenen Modulen/Komponenten.
Am Ende dann vor den ganzen Kladderadatsch eine möglichst intelligente
WAF zu hängen scheint mir jedenfalls auch nur ein herumdoktoren an den
Symptomen zu sein.
CISO schrieb: > Wenn niemand den Überblick über die > Versionsstände und Leichendeployments im Cluster hat, dann hat niemand > den Überblick. Und an der Stelle will ich ansetzen und die Entwickler > unterstützen, nicht knechten. Der Sinn von Docker und Kubernetes ist ja ausgerechnet dass diese Dinge in den Dockerfiles bzw am Kubernets-Master definiert sind...
vnnn schrieb: > Der Sinn von Docker und Kubernetes ist ja ausgerechnet dass diese Dinge > in den Dockerfiles bzw am Kubernets-Master definiert sind... Das ist schön. Dann wirst du sicher meine Ausgangsfrage beantworten können. Ich zitiere mich einmal selbst: CISO schrieb: > Gibt es Verfahren zur Etablierung von Freigabeprozessen und Überwachung > der Sicherheit in so einem Wildwest-Cluster oder ist das überhaupt nicht > vorgesehen? Also: Welche Tools schlägst du vor? Markus M. schrieb: > Manchmal frage ich mich dann, ob das alles noch sinnvoll handhabbar ist. > Oder ob man sich nicht mehr Probleme einfängt als löst durch die immer > weitere Segmentierung einer Lösung in eine unüberschaubare Anzahl an/von > extern eingebundenen Modulen/Komponenten. Bin da immer etwas zwiegespalten. Beim Beispiel Python gibt es zum Beispiel nicht alle Bibliotheken in den Betriebssystempaketquellen. Bei npm Paketen sieht es noch schlechter aus. Wenn jetzt jemand vielleicht sogar hingeht und den Sourcecode von Hand herunterlädt (und ggf. kompiliert/installiert) wird das auch nie wieder ein Update sehen. Da kann ein Docker Container schon ein Segen sein. Das Image muss sich aber dann entsprechend automatisch auf der Basis der aktuellsten Version regelmäßig neu bauen, testen und ausrollen. Das wiederrum ist in einer Produktivumgebung meist nicht gewollt und ebenfalls ein Sicherheitsrisiko. Momentan finde ich, dass Docker oft das schlechteste aus beiden Welten vereint. Erst werden Pakete aus den offiziellen Paketquellen in den Container installiert, dann bekommt dieser Container keine Updates, weil sich niemand kümmert. Dinge wie automatische Sicherheitsupdates funktionieren in Docker nur begrenzt bis gar nicht.
Markus M. schrieb: > Er ist der Meinung dass (pipenv) ist der optimale Weg, um sich eine > schöne stabile Pythonumgebung für die Entwicklung als auch Laufzeit zu > schaffen, unabhängig vom OS. Guter Kollege, recht hat er. Markus M. schrieb: > ein Einwand war, wie man denn - ggfs. > sicherheitsrelevante - Updates dann managed, wenn es jede Menge > individuelle Python-Envs jeweils mit eigenen lokalen Paketen gibt, die > munter mehr oder weniger eingefroren werden um eine "stabile" Umgebung > zu haben, und nicht vom normalen Patchprozess für das OS erfasst werden. Ein Script schrieben welches die ganzen Source-Repos abklappert und mir eine nette Mail schreibt wenn Abhängigkeiten nicht mehr aktuell sind. Dependabot wär da ein Beispiel. Wenn ich mich drauf verlassen kann dass der Packagemaintainer seine Versionierung im Griff hat (Semantic Versioning) kann ich im requirements.txt wahlweise auch angeben dass innerhalb einer Major- oder Minorversion automatisch aktualisiert wird. Gegenfrage, was machst du wenn das OS eine Abhängigkeit automatisch aktualisiert und plötzlich die Anwendung nicht mehr läuft? Markus M. schrieb: > Schlussendlich kamen wir dann dazu, dass man eigentlich Container bauen > müsste, nur die Frage wer dass dann am Ende alles managen soll (Updates > aller verwendeten Komponenten im Auge behalten, Container entsprechend > pflegen etc.) konnte er auch nicht wirklich beantworten. Container sind zwar nett, lösen in dem Fall aber gar nix. Virtual Environments ähneln Containern in der Hinsicht recht stark. Markus M. schrieb: > Oder ob man sich nicht mehr Probleme einfängt als löst durch die immer > weitere Segmentierung einer Lösung in eine unüberschaubare Anzahl an/von > extern eingebundenen Modulen/Komponenten. Natürlich kann man auch Monolithen bauen, kann für viele Anwendungen auch durchaus sinnvoll sein. Ab einer gewissen Systemgröße kann die halt keiner überblicken, es heißt nicht umsonst "teile und herrsche".
vnnn schrieb: > Wenn ich mich drauf verlassen kann dass > der Packagemaintainer seine Versionierung im Griff hat (Semantic > Versioning) kann ich im requirements.txt wahlweise auch angeben dass > innerhalb einer Major- oder Minorversion automatisch aktualisiert wird. > Gegenfrage, was machst du wenn das OS eine Abhängigkeit automatisch > aktualisiert und plötzlich die Anwendung nicht mehr läuft? Zwar nicht ganz passend, aber: Wie mache ich Semantic Versioning in Docker Images sinnvoll? Normalerweise startet meine CI/CD Pipeline, bei einem Commit bzw. Release, baut das Image und pushed es in die Registry unter einem neuen Tag. Von da aus kann ich es sinnvoll zuordnen und (automatisch) ausrollen. Bis hierhin einfach. Jetzt habe ich ein Teilprojekt, das praktisch fertigentwickelt ist. Hier finden vielleicht nur wenige Commits und Releases im Jahr statt. Das Basisimage bekommt aber trotzdem Sicherheitsupdates. Wenn ich das Image jetzt automatisiert jede Nacht neu baue, um diese Updates mitzunehmen, welche Versionsnummer erhält es dann und woher beziehe ich diese Versionsnummer in meiner Pipeline im Gitlab?
CISO schrieb: > Aber um das nochmal zu konkretisieren: Ich kann organisatorisch so viele > Regeln wie ich will erlassen. Hilft nur keinem solang sich niemand an Deine Regeln hält. Solche Regeln hätte es schon lange geben und sie hätten durchgesetzt werden müssen. Das ist nicht passiert, sonst wärst Du nicht in dieser nisslichen Lage. > Wenn niemand den Überblick über die > Versionsstände und Leichendeployments im Cluster hat, dann hat niemand > den Überblick. Auch wenn Du es nicht wahr haben willst, ist das auch Folge eines organisatorischen Versagens. Wenn Du diese Ursache nicht anpackst werden die Probleme immer wieder kommen. > Und an der Stelle will ich ansetzen und die Entwickler > unterstützen, nicht knechten. Was hindert Dich daran? Ausser dass es nicht Dein Job ist, natürlich. > Hier versteht das offenbar keiner. Ist ja auch das erste Mal dass Du sowas sagst. Bisher hast Du Dich nur beklagt und alle anderen für Fehler verantwortlich gemacht, die Du und Deine Kollegen begangen habt.
Bei uns gibt es einen build server, und einen, wo die artefakte rein kommen. Auch container images und so. Wir haben eine fixe pipeline, vom push bis ins k8s. Als basis kann man nur vordefinierte Container nehmen, direkter Internetzugriff beim Builden gibts auch nicht, auch npm Packete usw. müssen über die interne registry. Die Basiscontainer werden regelmässig automatisch rebuildet. Und es gibt scanner, die schauen, ob die verwendeten Container und Pakete keine CVEs haben. Wenn da welche sind, muss der Entwickler da nochmal ran. Wir haben test und prod Umgebungen, da müssen jeweils erst tests gefahren werden. Aber fragt mich nicht, wie die das umgesetzt haben, das k8s zeug wird in einer anderen Abteilung verwaltet.
Kiffer schrieb: > Hilft nur keinem solang sich niemand an Deine Regeln hält. Solche Regeln > hätte es schon lange geben und sie hätten durchgesetzt werden müssen. > Das ist nicht passiert, sonst wärst Du nicht in dieser nisslichen Lage. Bla Kiffer schrieb: > Auch wenn Du es nicht wahr haben willst, ist das auch Folge eines > organisatorischen Versagens. Wenn Du diese Ursache nicht anpackst werden > die Probleme immer wieder kommen. Bla Kiffer schrieb: > Was hindert Dich daran? Ausser dass es nicht Dein Job ist, natürlich. Bla Kiffer schrieb: > Ist ja auch das erste Mal dass Du sowas sagst. Bisher hast Du Dich nur > beklagt und alle anderen für Fehler verantwortlich gemacht, die Du und > Deine Kollegen begangen habt. Bla
DPA schrieb: > Als basis kann man nur vordefinierte Container nehmen, > direkter Internetzugriff beim Builden gibts auch nicht, auch npm Packete > usw. müssen über die interne registry. Die Basiscontainer werden > regelmässig automatisch rebuildet. Das klingt zwar nach Schmerzen, aber nach einem sinnvollen Weg. Danke, das hilft mir weiter.
Markus M. schrieb: > Er ist der Meinung dass (pipenv) ist der optimale Weg, um sich eine > schöne stabile Pythonumgebung für die Entwicklung als auch Laufzeit zu > schaffen, unabhängig vom OS. Mein Einwand war, wie man denn - ggfs. > sicherheitsrelevante - Updates dann managed, wenn es jede Menge > individuelle Python-Envs jeweils mit eigenen lokalen Paketen gibt, die > munter mehr oder weniger eingefroren werden um eine "stabile" Umgebung > zu haben, und nicht vom normalen Patchprozess für das OS erfasst werden. > > Schlussendlich kamen wir dann dazu, dass man eigentlich Container bauen > müsste, nur die Frage wer dass dann am Ende alles managen soll (Updates > aller verwendeten Komponenten im Auge behalten, Container entsprechend > pflegen etc.) konnte er auch nicht wirklich beantworten. Genau das sind doch die Umgebungen, die virtualenv, venv, pipev und Poetry bauen: genau reproduzierbare Container als Abstraktion zwischen Interpreter, Bibliotheken und der Laufzeitumgebung. Ja, die muss man aktualisieren. Dazu gibt es etablierte Lösungen für CI und CD, automatisierte Tests mitsamt Spässen wie Selenium und AutoIt, und natürlich ein Monitoring für die (hoffentlich zunehmend seltenen Fälle) in denen das mal nicht so perfekt wie geplant klappt. Mit ein bisschen Hirnschmalz kann man mit Technologien wie Docker und Co im Fehlerfall sogar auf die Vorversion zurückrollen, bis die neue Version läuft.
CISO schrieb: >angen habt. > Bla Na Du bist ja mal so ein richtig konstruktiver Typ. Kein Wunder dass Du in Deinem Job versagst.
Kiffer schrieb: > Genau das sind doch die Umgebungen, die virtualenv, venv, pipev und > Poetry bauen: genau reproduzierbare Container als Abstraktion zwischen > Interpreter, Bibliotheken und der Laufzeitumgebung. > > Ja, die muss man aktualisieren. Dazu gibt es etablierte Lösungen für CI > und CD, automatisierte Tests mitsamt Spässen wie Selenium und AutoIt, > und natürlich ein Monitoring für die (hoffentlich zunehmend seltenen > Fälle) in denen das mal nicht so perfekt wie geplant klappt. Mit ein > bisschen Hirnschmalz kann man mit Technologien wie Docker und Co im > Fehlerfall sogar auf die Vorversion zurückrollen, bis die neue Version > läuft. Ja, das muss aber alles erst einmal da sein und gepflegt werden. Und wenn das nicht der Fall ist, würde ich im Zweifelsfall lieber auf das letzte Funky-Feature von Python verzichten und die Version nehmen, die das OS mitbringt. Ist komplett "oldschool", reißt einem aber nicht ungewollte Probleme irgendwo rein.
Kiffer schrieb: > CISO schrieb: >>angen habt. >> Bla > > Na Du bist ja mal so ein richtig konstruktiver Typ. Kein Wunder dass Du > in Deinem Job versagst. Bla. Dann schreib doch mal was konstruktives. Aber bist du wohl zu bekifft zu.
Markus M. schrieb: > Ja, das muss aber alles erst einmal da sein und gepflegt werden. Und > wenn das nicht der Fall ist, würde ich im Zweifelsfall lieber auf das > letzte Funky-Feature von Python verzichten und die Version nehmen, die > das OS mitbringt. Ist komplett "oldschool", reißt einem aber nicht > ungewollte Probleme irgendwo rein. Obwohl ich sie nicht teile, verstehe ich Deine Überlegungen. Dennoch kannst Du die nötige Softwarepflege dadurch höchstens verschieben. Das eigentliche Problem -- daß Software nun einmal gepflegt werden muß und daß das Aufwände erfordert -- löst Du mit Deinem Ansatz leider nur kurzfristig, während Du anderswo womöglich neue Probleme provozierst.
Ein T. schrieb: > Obwohl ich sie nicht teile, verstehe ich Deine Überlegungen. Dennoch > kannst Du die nötige Softwarepflege dadurch höchstens verschieben. Das > eigentliche Problem -- daß Software nun einmal gepflegt werden muß und > daß das Aufwände erfordert -- löst Du mit Deinem Ansatz leider nur > kurzfristig, während Du anderswo womöglich neue Probleme provozierst. Okay. Was ist dein Lösungsvorschlag?
Mach es einfach so wie ich es dir gesagt habe. Vordefinierte basiscontainer, und ein Scanner der bei den Artefakten regelmässig schaut, ob es zu den npm/pip/etc. Abhängigkeiten bekannte CVEs gibt. Dann Tickets eröffnen, und die devs fixen lassen.
🐧 DPA 🐧 schrieb: > Mach es einfach so wie ich es dir gesagt habe. Vordefinierte > basiscontainer, und ein Scanner der bei den Artefakten regelmässig > schaut, ob es zu den npm/pip/etc. Abhängigkeiten bekannte CVEs gibt. > Dann Tickets eröffnen, und die devs fixen lassen. Ja, gerne sogar. Habe ich ja schon kommentiert. Trotzdem darf ein_typ sich als Quell der ewigen Weißheit gerne ebenfalls dazu äußern.
CISO schrieb: > 🐧 DPA 🐧 schrieb: > >> Mach es einfach so wie ich es dir gesagt habe. Vordefinierte >> basiscontainer, und ein Scanner der bei den Artefakten regelmässig >> schaut, ob es zu den npm/pip/etc. Abhängigkeiten bekannte CVEs gibt. >> Dann Tickets eröffnen, und die devs fixen lassen. > > Ja, gerne sogar. Habe ich ja schon kommentiert. Trotzdem darf ein_typ > sich als Quell der ewigen Weißheit gerne ebenfalls dazu äußern. Der war gut. Da hast du den Schaumschläger mal richtig vorgeführt. Respekt ✅
Helmut schrieb: > Der war gut. Da hast du den Schaumschläger mal richtig vorgeführt. > Respekt ✅ Und wie erwartet hat ein_typ tatsächlich nichts zu sagen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.