Forum: PC Hard- und Software Rant über die Unsicherheiten von Docker/Kubernetes


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von CISO (Gast)


Lesenswert?

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?

von Rubble C. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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?

von CISO (Gast)


Lesenswert?

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ä?

von Reinhard S. (rezz)


Lesenswert?

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.

von 60/40 (Gast)


Lesenswert?

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.

von Jan K. (jan_k)


Lesenswert?

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.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Rubble C. (Gast)


Lesenswert?

^ auf den Punkt gebracht.

von Stefan F. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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
von Εrnst B. (ernst)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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

von Εrnst B. (ernst)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche) Flattr this


Lesenswert?

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.

von Risiko (Gast)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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.

von Reinhard S. (rezz)


Lesenswert?

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

von Helmut (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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. ;-)

von CISO (Gast)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ist doch kein Problem. Gibt ja zeugs wie z.B. stunnel

Ist kein Problem, wenn der Kunde das so akzeptiert. Wenn ...

von Markus M. (adrock)


Lesenswert?

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.

von vnnn (Gast)


Lesenswert?

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

von CISO (Gast)


Lesenswert?

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.

von vnnn (Gast)


Lesenswert?

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

von CISO (Gast)


Lesenswert?

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?

von Kiffer (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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

von CISO (Gast)


Lesenswert?

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.

von Kiffer (Gast)


Lesenswert?

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.

von Kiffer (Gast)


Lesenswert?

CISO schrieb:
>angen habt.
> Bla

Na Du bist ja mal so ein richtig konstruktiver Typ. Kein Wunder dass Du 
in Deinem Job versagst.

von Markus M. (adrock)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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.

von Kiffer (Gast)


Lesenswert?

CISO schrieb:
> Bla.

So "konstruktiv" wie Du? Kein Mensch der Welt könnte so viel kiffen.

von Ein T. (ein_typ)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

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.

von CISO (Gast)


Lesenswert?

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

von Helmut (Gast)


Lesenswert?

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 ✅

von CISO (Gast)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.