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