Transcript
Kai Ole Hartwig: Ja, willkommen zur zweiten Folge Secrets Not Included.
Kai Ole Hartwig: Wieder Daniel und Ole hier.
Kai Ole Hartwig: Und wir haben uns gedacht, wir sprechen heute mal über Secrets und Geheimnisse.
Kai Ole Hartwig: Einfach frei raus, was machen wir da und verraten jetzt doch alle Geheimnisse.
Daniel Langemann: Genau.
Kai Ole Hartwig: Oder Daniel?
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, genau.
Daniel Langemann: Alles wird öffentlich, wie es sich nicht gehört.
Daniel Langemann: Ne, das passt ja zum Titel.
Daniel Langemann: Und wir hatten uns vorhin schon zusammengesetzt und darüber gesprochen, was für Themen könnten interessant sein, was wollen wir erzählen, was wollen wir nicht erzählen.
Daniel Langemann: Und dabei ist eigentlich die Abkürzung SOPS gefallen.
Kai Ole Hartwig: Genau.
Daniel Langemann: Und ich habe keinen Plan, was das ist.
Kai Ole Hartwig: SOPS ist eigentlich ein schönes Tool, um Secrets zu verschlüsseln.
Kai Ole Hartwig: Also Secrets Operations heißt es.
Kai Ole Hartwig: Ist, glaube ich, ursprünglich von Mozilla entwickelt worden und
Kai Ole Hartwig: Kurz gesagt, kannst du damit alle Secrets mit zum Beispiel AID, PGP oder auch HashiCorp Vault entsprechend verschlüsseln und nachher auch wieder entschlüsseln.
Daniel Langemann: Achso, das bezeichnet also eine Toolgruppe, so wie ich jetzt AWS Secrets Manager oder Parameter Store, jetzt HashiCorp Vault kenne ich auch.
Kai Ole Hartwig: Genau, das
Daniel Langemann: Das bezeichnet die Toolgruppe also.
Daniel Langemann: Okay.
Daniel Langemann: Okay.
Kai Ole Hartwig: Ja, also keine Toolgruppe, sondern es ist halt ein CLI-Tool, um Secrets zu managen oder vielmehr um Dateien zu verschlüsseln und entschlüsseln mit einem Key deiner Wahl.
Kai Ole Hartwig: Und dabei fällt dann halt eine Datei raus, die ist verschlüsselt, die kannst du im Git tracken für GitOps nutzen und dann kann aber dein Secret nicht jeder lesen.
Daniel Langemann: Ja, also basierend auf asynchroner Verschlüsselung.
Daniel Langemann: Immer nach dem Konzept, es gibt ein Public und Private Key.
Daniel Langemann: Public liegt im Projekt mit drin.
Daniel Langemann: Ich kann sagen, ich möchte das Datenpasswort ändern, schreibe es rein, es wird verschlüsselt, im Git abgelegt.
Daniel Langemann: Und auf dem Zielsystem liegt irgendwo wirklich abgesichert dann der Private Key, wo das dann sozusagen zur Laufzeit entschlüsselt wird und möglichst wenig Credentials irgendwo rumliegen, sage ich mal.
Daniel Langemann: Oder?
Kai Ole Hartwig: Umgekehrt, zum Verschlüsseln den Private Key, zum Entschlüsseln den Public Key, oder?
Daniel Langemann: Nein, der sollte ja...
Kai Ole Hartwig: Warte mal, wir müssen das schneiden.
Daniel Langemann: Nein, nein, genau das ist es doch.
Daniel Langemann: Also asynchrone Verschlüsselung funktioniert ja in beide Richtungen.
Kai Ole Hartwig: Genau.
Daniel Langemann: Wenn ich den Private Key... Moment, was habe ich jetzt gesagt?
Daniel Langemann: Ich habe genau falschrum gesagt, ne?
Daniel Langemann: Ich habe die... Ja.
Kai Ole Hartwig: Also du wolltest mit dem Public Key verschlüsseln und mit dem Private Key entschlüsseln.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ich würde gerne mit dem Private Key verschlüsseln und mit dem Public Key entschlüsseln.
Daniel Langemann: Genau so möchte ich das aber, weil nur das Produktivsystem soll ja sehen, welche Passwörter
Daniel Langemann: in unserem Git-Repo drin liegen.
Daniel Langemann: Und mal abgesehen jetzt von dem Fall selber, Public und Private Key funktioniert ja so, aus der E-Mail-Verschlüsselung oder Signaturen genauso, ist ja so, wenn ich diesen Private Key habe, den ich nirgendwo rausgeben darf, kann ich mich ja authentifizieren als Nutzer XY, wenn derjenige meinem Private Key vertraut.
Daniel Langemann: Heißt, mir können alle Menschen eine E-Mail schicken und verschlüsseln und ich bin der Einzige, der sie mit diesem Private Key entschlüsseln kann.
Kai Ole Hartwig: Stimmt, du hast absolut recht und ich sollte vielleicht kein Secret Management mit Kopfschmerzen machen.
Kai Ole Hartwig: Ja, natürlich, natürlich.
Daniel Langemann: Das haben wir extra eingebaut zum Zeigen und damit ich was erklären kann.
Kai Ole Hartwig: Ja, du hast selbstverständlich an der Stelle recht.
Daniel Langemann: Genau.
Kai Ole Hartwig: Die Secrets sollte man nur entschlüsseln können, wenn man den passenden Key hat.
Kai Ole Hartwig: So, das war's, fertig.
Kai Ole Hartwig: Und alle Secrets sind sicher, weil wir haben sie jetzt dann doch irgendwie im Git getrackt, obwohl es ja eigentlich Best Practice ist, die gar nicht ins Git zu schmeißen.
Kai Ole Hartwig: Vom Grundsatz her möchte man ja eigentlich gar keine Geheimnisse im Git haben.
Kai Ole Hartwig: Das geht aber ja explizit und unumstößlich für nicht verschlüsselte Geheimnisse.
Daniel Langemann: Also einfach mit dem Hintergrund, ich möchte zum Beispiel im Produktivsystem das Datenbank-Passwort polieren können.
Daniel Langemann: Bei AWS gibt es die Möglichkeit, viele andere machen das auch.
Daniel Langemann: Täglich, wöchentlich, was auch immer, zu gewissen Uhrzeiten ändert sich das Passwort, ohne dass die Applikation irgendwie neu deployed werden muss oder dass ein Entwickler das theoretisch dann committen müsste, pushen müsste, ein Deployment machen müsste.
Daniel Langemann: Das wäre ja viel zu umständlich und genau deswegen möchte man auch noch, also mal abgesehen von dem Sicherheitsfaktor, auch die Secrets nicht im Projekt haben, damit die einfach geändert werden können.
Daniel Langemann: Oder zum Beispiel auch Entwickler.
Daniel Langemann: Ich als Entwickler muss keine Credentials für irgendwelche Produktivsysteme haben.
Daniel Langemann: Ich muss nicht auf Kundendaten zugreifen können, das ist oft auch ein Sicherheitsproblem.
Daniel Langemann: Ich darf nicht in der Datenbank suchen können nach Nutzern, die mich nichts angehen.
Daniel Langemann: Und oft ist es so in größeren Teams, dass Ops, also Operations, sich um Credentials, um Betrieb kümmert.
Daniel Langemann: Da ist protokolliert mit Zugriff und, und, und, wer wann wo wie darauf zugreifen darf.
Daniel Langemann: Und ich als Entwickler habe eine Testdatenbank mit unkritischen Daten oder mit irgendwelchen Feature-Daten.
Kai Ole Hartwig: Vielen Dank.
Daniel Langemann: Und kann die dann nacharbeiten und möchte auch gar nicht.
Daniel Langemann: Also umgekehrt genauso, wenn es irgendwann mal einen Sicherheitsvorfall gibt, bin ich als Entwickler sogar froh, einfach gar nicht zum Kreis der Verdächtigen zu gehören, weil ich nie diese Credentials in der Hand hatte oder hätte haben können.
Kai Ole Hartwig: Ja, ich finde, es ist auch immer total schön, Cludentials gar nicht zu kennen.
Kai Ole Hartwig: Also wenn ich die Passwörter nicht kenne und gar keinen Zugriff auf diese Systeme haben kann, bedeutet das auch, ich kann die nie verlieren.
Daniel Langemann: Ja, genau.
Kai Ole Hartwig: Ja, also ob absichtlich oder unabsichtlich.
Kai Ole Hartwig: Stell dir mal vor, du hast die Sachen einfach so im Git liegen oder meinetwegen auch eine Kopie vom Produktivsystem runtergezogen, hast jetzt alle Bestellungen zum Beispiel aus dem Shop bei dir liegen oder alle Kontaktanfragen mit allen personenbezogenen Daten und durch einen dummen Zufall vergisst du deinen USB-Stick in der Bahn, wo diese Daten drauf waren.
Kai Ole Hartwig: So.
Daniel Langemann: Lustige Geschichte dazu.
Daniel Langemann: Stell dir mal, du testest einen Newsletter lokal und nutzt dann aus Versehen mal richtige Credentials für ein Produktivsystem und sendest diese Newsletter raus.
Daniel Langemann: Und wenn du dann auch noch Pech hast und dann irgendwie, sagen wir mal, ein Geschlechtsteil als irgendwie Titel oder so nutzt, dann geht das an Kunden raus.
Daniel Langemann: Das ist sehr peinlich, aber eine coole Geschichte für Jahre später zum Erzählen.
Daniel Langemann: Also...
Kai Ole Hartwig: Ich frage jetzt nicht, wie du auf diese Geschichte kommst und wie der Titel dieses Newsletters zustande gekommen ist.
Daniel Langemann: Ja.
Daniel Langemann: Ja, ja.
Daniel Langemann: Das wäre mal ein anderes Thema.
Daniel Langemann: Oh ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Aber definitiv, wir haben also Dinge, die man nicht hat, kann man nicht verlieren und nicht seltsam benutzen.
Kai Ole Hartwig: Ja, wäre nächste Woche dann, übernächste Woche dann das Thema, warum der Newsletter so hieß, wie er hieß?
Kai Ole Hartwig: Okay.
Kai Ole Hartwig: Ich meine, das ist ja auch so ein Grundgedanke, an den man sich vielleicht auch so ein bisschen gewöhnen muss, wenn man etwas kleinere Projekte hat oder übersichtlichere Teams, dass
Kai Ole Hartwig: Secrets halt auch einfach nicht in den produktiven Container gehören, dass sie immer von außen reinkommen sollten.
Kai Ole Hartwig: Und auch an der Stelle ist ja SOPS auch so ein bisschen, also ich finde, das ist eine schöne Lösung für etwas kleinere Setups, wo ich halt nicht zur Laufzeit meines Secrets direkt reingeben kann.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Also ich persönlich bevorzuge halt irgendwie ein Vault oder ein anderes Secret-Management, meinetwegen über einen Sidecar-Container in der Laufzeitumgebung, um ehrlich zu sein, als dass ich sage, ja, okay, jetzt habe ich das in der Daten, im Git liegen meine Secrets und dann schlüssel ich die und gebe die dann rein.
Kai Ole Hartwig: Ja, ich finde das immer total sympathisch, Secrets quasi nur in der Runtime zu haben,
Kai Ole Hartwig: in dem Web-Container zum Beispiel, der sie braucht.
Kai Ole Hartwig: Und dann, ich sage jetzt mal, nicht über Environment-Variablen oder ähnliches rumliegen zu haben, damit halt auch da nicht über irgendeinen Dump oder Mitschnitt vom Log halt diese Secrets rauskommen können.
Daniel Langemann: Mhm.
Daniel Langemann: Yep.
Kai Ole Hartwig: Man hält die halt schön raus und damit macht man halt auch Secret Management einfach.
Kai Ole Hartwig: Ja, ich meine, klar, so kannst du halt auch einfach neu deployen, hast neue Secrets drin, alles cool.
Kai Ole Hartwig: Aber so ein losgelöstes Tool, das dann vielleicht auch selbstständig da läuft, wo du Regeln definieren kannst mit, hey, okay, gut, hier alle fünf Minuten.
Kai Ole Hartwig: Bisschen übertrieben, aber
Kai Ole Hartwig: rotiere halt alle 30 Tage hier diese Daten und alle x Tage die anderen Daten.
Kai Ole Hartwig: Das erhöht halt ja auch nochmal die Sicherheit einfach, dass wenn alles ordnungsgemäß konfiguriert ist und einfach das Secret Management da läuft, abgeschottet ist und so weiter, dass
Kai Ole Hartwig: selbst wenn mal Daten verloren gehen, die einfach nicht langlebig sind, nicht langlebig, wenn Zugriff darauf möglich ist, dann hat halt mal jemand für x Tage Zugriff gehabt, das ist schlimm genug, aber wir haben eine Maßnahme und eine Methode, die durch Regelmäßigkeit dafür sorgt, dass der Schaden kleiner bleibt.
Daniel Langemann: Ja, es geht ja auch nicht darum, oh sorry.
Kai Ole Hartwig: So, jetzt muss... Ne, ne, mach ruhig.
Kai Ole Hartwig: Da bricht mich.
Daniel Langemann: Es geht ja auch nicht darum, wirklich hundertprozentige Sicherheit, die gibt es nicht.
Daniel Langemann: Nichts ist hundertprozentig sicher.
Daniel Langemann: Es geht ja nur darum, mit den Maßnahmen es möglichst schwer zu machen.
Daniel Langemann: Zum Beispiel an Credentials zu kommen, in Systeme reinzukommen,
Daniel Langemann: Auch Verschlüsseln, sagen wir mal, wenn man genug Rechenleistung im Hintergrund hat und es ist eine schlechte Verschlüsselung gewählt, kann man solche Sachen auch aushebeln.
Daniel Langemann: Es gibt genug Einwände, wo man sagen könnte, ist auch das Verschlüsseln zur Laufzeit, wenn jemand Zugriff auf den Container hat zum Beispiel, irgendwo müssen die Sachen ja auch wieder entschlüsselt sein und sind dann auch zugreifbar.
Kai Ole Hartwig: Genau.
Daniel Langemann: Aber es ist halt so, die liegen nicht leicht zugänglich.
Daniel Langemann: Also das beste Beispiel ist einfach den Schlüssel unter die Fußmatte legen.
Daniel Langemann: Das wollen wir nicht.
Daniel Langemann: Also es soll eine vernünftige Tür da sein, die Fenster sollen zu sein.
Daniel Langemann: Wir wollen den Schlüssel nicht unter die Fußmatte legen, damit derjenige gar nicht, also es nicht leicht hat, ins System zu kommen.
Daniel Langemann: Und je mehr man macht, umso besser ist auch oft die Sicherheit.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich glaube gar nicht je mehr, sondern je durchdachter, finde ich.
Kai Ole Hartwig: Also ich meine, es hilft jetzt ja nicht, alles Mögliche draufzuschmeißen und zu verstecken und zu sagen, ja, meinen SSH-Port, den lege ich jetzt von 22 auf 2222 oder irgendwie sowas und ich ändere alle Standards-Ports und so, da geht es ja gar nicht drum.
Kai Ole Hartwig: Also Sachen verstecken, ähm,
Kai Ole Hartwig: Hilft ja nicht.
Kai Ole Hartwig: Irgendwann findet man, wenn man lang genug sucht und wir können automatisch suchen.
Kai Ole Hartwig: Das ist nicht wie, wenn ich den Hausschlüssel finden muss, unter welchem Blumenpott steht.
Kai Ole Hartwig: Liegt der jetzt, weil unter der Hausmatte wollte ich ihn ja nicht, sondern das funktioniert ja gleichzeitig und automatisch.
Kai Ole Hartwig: Sprich, ich finde, das ganze Secret Management und welche Sicherheitsmaßnahmen man macht, sollte halt durchdacht sein.
Kai Ole Hartwig: Ja, auch so etwas wie, hey, wenn ich von außen komme, dann komme ich halt grundsätzlich nur über meine beiden Ports, die dafür vorgesehen sind.
Kai Ole Hartwig: 80 und von 80 werde ich auf 443 auf HTTPS umgeleitet und dann ist das meine Zugriffsmöglichkeit.
Kai Ole Hartwig: Und wenn ich dann auch nur mit der Route nur auf den Webserver draufkomme und auf gar nichts, was dahinter liegt, alles andere muss da durchlaufen, dann ist ja schon mal ein deutlicher Schritt gemacht.
Kai Ole Hartwig: Ja, da müsste ich ja einen Weg finden, in diesen Container reinzukommen oder in dieses System reinzukommen und von dort aus weiterzukommen.
Kai Ole Hartwig: Klar, wenn ich es geschafft habe, reinzukommen, dann ist es immer noch schön, wenn es, ähm,
Kai Ole Hartwig: Maßnahmen gibt es, die dafür sorgen, dass es schwierig ist, drinnen zu bleiben.
Daniel Langemann: Ja.
Kai Ole Hartwig: Oder schwierig ist halt, die Credentials auszulesen, weil man sie halt nicht einfach mit Print Env oder so ausgeben kann.
Kai Ole Hartwig: Und das sind ja so diese Schritte, wenn man, ich finde, wenn man so ein paar durchdachte Dinge tut,
Kai Ole Hartwig: dann erhöht man halt die Sicherheit auch unfassbar.
Kai Ole Hartwig: Ja, wie zum Beispiel, dass auch einfach nur ein Entry Point, eine Index-PHP, da liegt in diesem Public-Verzeichnis und alles andere liegt außerhalb von dem Web-Root, dann erhöht das halt auch schon mal die Wahrscheinlichkeit,
Kai Ole Hartwig: das erhöht den Aufwand darauf zuzugreifen und die Wahrscheinlichkeit, dass einfach eine Sicherheitslücke ausgenutzt werden kann.
Kai Ole Hartwig: Selbst wenn sie drin ist, muss man halt nochmal eine Schippe drauflegen, um sie ausnutzen zu können.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und ich sage jetzt mal, je mehr Schichten,
Kai Ole Hartwig: von so einem Emmentaler mit den großen Löchern du aufeinanderlegst.
Kai Ole Hartwig: Je undurchlässiger wird das ja.
Kai Ole Hartwig: Wenn du das dann irgendwann hochhältst, siehst du ja auch keine direkte Lücke mehr.
Kai Ole Hartwig: Da sind zwar überall Löcher drin, aber die verdecken sich halt gegenseitig und dann kannst du halt nicht durchschauen.
Kai Ole Hartwig: Und, ähm,
Kai Ole Hartwig: Ich finde, das ist eigentlich ein schönes Bild aus Maßnahmen, die man machen kann, wozu halt auch das Secret Management einfach als eine Ebene da drin gehört, zusammen mit der Secret Rotation.
Kai Ole Hartwig: Wir wissen ja eigentlich auch, langlebige Credentials sind halt das höchste Risiko.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Wenn wir so ein API Key nie ändern über ein Jahr oder noch länger,
Kai Ole Hartwig: dann geht er halt mit hoher Wahrscheinlichkeit dann doch irgendwann mal verloren.
Kai Ole Hartwig: Und da finde ich das total wichtig.
Kai Ole Hartwig: Jetzt gehen wir beide natürlich wieder davon aus, dass wir in einer schönen, containerisierten Welt sind, in der wir sowas haben.
Kai Ole Hartwig: Ich finde, da ist es deutlich schwieriger mit umzugehen,
Kai Ole Hartwig: wenn wir halt auf einem Standard-V-Host-Setup oder Shared-Setup sind.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Weil da wird es natürlich sehr, sehr schwierig, das oder schwieriger, entsprechende Maßnahmen zu machen.
Kai Ole Hartwig: Einfach weil du dann ja in der Situation bist, alles liegt auf dem gleichen Ding drauf.
Daniel Langemann: Also da bieten sich ja dann von HashiCorp Vault, AWS Parameter Store oder Secrets Manager schon fast an, weil die recht einfach einzubauen sind,
Daniel Langemann: zur Laufzeit die Daten abrufen, heißt auf dem V-Host, wie auch immer geartet, liegen die nicht permanent auf der Platte, sondern maximal in einem Cache, den man natürlich auch mit Schreibrechten und so weiter auch nochmal absichern sollte.
Daniel Langemann: Aber das ist schon mal ein guter Schritt, dass man dann die Credentials da drin hat und nicht in Umgebungsvariablen, wo andere Applikationen darauf zugreifen könnten oder in Dateien zum Beispiel.
Daniel Langemann: Das wäre ja so ein bisschen der Super-GAU.
Daniel Langemann: Es gibt auch für kleinere Projekte, also wenn man die Komplexität nicht explodieren lassen will, weil nicht jeder hat oder nicht jede Firma hat dann noch einen AWS-Account, wo jeder Zugriff drauf hat und wo das verwaltet wird, wo man sowas machen kann.
Daniel Langemann: Also zum Beispiel von Symfony gibt es das auch.
Daniel Langemann: dass man Secrets verwalten kann.
Daniel Langemann: Genau nach diesem Konzept mit Public Key, Private Key.
Daniel Langemann: Man müsste jetzt bei diesem V-Host natürlich gucken, was macht man mit diesem Private Key, damit theoretisch nur die eine Applikation darauf zugreifen kann.
Daniel Langemann: mit wem teilt man sich das?
Daniel Langemann: Ist man der alleinige Herrscher auf dem System oder gibt es da andere Abteilungen, die nicht zugreifen sollen?
Daniel Langemann: Das wäre natürlich alles interessant, aber in meiner kleinen idealen Welt bin ich alleine dafür zuständig, habe als einziger Handgriff drauf und dann könnte man zum Beispiel auch sowas, also ohne die Komplexität mit externen Tools in die Höhe zu treiben, sowas machen oder habe ich auch schon mal selber gebaut für ein Projekt, auch kleines Projekt, genau diese Konstellation.
Kai Ole Hartwig: Vielen Dank.
Daniel Langemann: Ich habe die Kontrolle über den Host,
Daniel Langemann: Ich will die nicht im Git drin haben, die Credentials, also nicht im Klartext drin haben, genau das Spielchen mit GPG, einfach lokal mit dem Public Key Sachen verschlüsselt, die Datei mit eingecheckt, beim Auschecken zur Laufzeit einfach mit dem Private Key dann
Daniel Langemann: entschlüsselt, in den Cache abgelegt und also wenn er halt, wenn der Cache leer war oder ein Cache miss war, einmal entschlüsselt, das war ein bisschen länger natürlich, nicht optimal, was Ladezeiten betrifft, aber das war einer von zigtausend Requests, also das war in Ordnung.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und dann hat man da eigentlich auch schon ein sehr gutes Setup, ohne dass man irgendwie Großunternehmenskontext unterwegs ist, wo man eine eigene Operations-Abteilung hat und die einem da auch dann zuarbeitet.
Kai Ole Hartwig: Ja, aber ich finde tatsächlich, dieses Secret-Management auf V-Host ist halt sehr schwierig, weil alles ist im gleichen Ding.
Kai Ole Hartwig: Irgendwie hat dann doch dieser V-Host-User Zugriff auf alles.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Da wird es glaube, also ich finde, das ist immer so das, wo ich sage, okay, alle Konzepte, die wir so normalerweise fahren und machen, ähm,
Kai Ole Hartwig: die werden da schwierig.
Kai Ole Hartwig: Wofür verschlüssel ich irgendwo ein Secret, wenn ich den Key quasi daneben legen muss und jeder kommt da dran?
Kai Ole Hartwig: Ich sage jetzt mal für den ungeübten, nicht Linux-affinen Menschen, der da draufkommt, falls es das denn gibt,
Kai Ole Hartwig: wäre das sicherlich zumindest, also man sucht zumindest ein bisschen, bis man das entschlüsselt, bis man den Key gefunden hat.
Kai Ole Hartwig: Fünf Minuten.
Kai Ole Hartwig: Aber, ja, bedeutet halt, es ist zumindest ein Schutz da, dass ein Entwickler die Dinge nicht so einfach verliert.
Kai Ole Hartwig: Oder nicht unverschlüsselt verliert.
Daniel Langemann: Um bei unserer Metapher zu bleiben, wir haben einen großen Stein auf die Matte gelegt.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, immerhin.
Kai Ole Hartwig: Immerhin den großen, ne?
Kai Ole Hartwig: Aber ich meine, ich finde ja auch Schlüssel im Blumentopf viel sympathischer als eine Löffnungsmatte.
Daniel Langemann: Ja.
Daniel Langemann: Aber nicht, wenn es friert.
Daniel Langemann: Mhm.
Daniel Langemann: Genau.
Kai Ole Hartwig: Das kommt halt drauf an, wo der Topf steht.
Kai Ole Hartwig: Oder die Fußmatte.
Kai Ole Hartwig: Naja, wenn das schön wettergeschützt ist, ist das vielleicht eine Option.
Daniel Langemann: Ich werde mal bei dir vorbeifahren und gucken.
Daniel Langemann: Ja, mache ich.
Daniel Langemann: Ja.
Kai Ole Hartwig: Mach das, mach das, bitte.
Kai Ole Hartwig: Und wenn du dann vor der Tür stehst, schön lächeln für die Kamera und winken.
Kai Ole Hartwig: Gut.
Kai Ole Hartwig: Heißt, aber wir beide sind großer Fan davon, Secrets nicht zu kennen, Credentials nicht zu kennen.
Kai Ole Hartwig: und sind auch damit glücklich und fein, wenn wir gar keine Produktivdaten haben, weil wir beide eigentlich gerne Dinge verlieren, das aber nicht so sagen.
Daniel Langemann: Exakt.
Kai Ole Hartwig: Perfekt.
Daniel Langemann: Gerade das Verlieren ist schlimm.
Daniel Langemann: Ja, es ist so.
Daniel Langemann: Also, dass etwas schief geht, kannst du nie ausschließen.
Daniel Langemann: Ich habe schon so viele Sachen gemacht, wo ich entweder Glück hatte, dass es nicht schiefgegangen ist, als Junior zum Beispiel, weil man einfach Sachen ausprobiert hat, wo man dann im Nachhinein sagt, mein Gott, das hätte wirklich schiefgehen können, weil da war ein Produktiv... Also, das beste Beispiel ist immer, du musst ein Produktivsystem, irgendwelche Credentials nutzen, weil es deine Applikation...
Kai Ole Hartwig: Ja.
Daniel Langemann: Meistens ist es mit Paymentsachen, es gibt oft keine Testumgebung fürs Payment oder das Testsystem ist irgendwie anders konfiguriert.
Daniel Langemann: Ja, natürlich macht man das.
Daniel Langemann: Man kopiert sich dann Credentials in seine lokale Entwicklungsumgebung und macht irgendwas, überlegt gerade nicht, schmeißt nochmal die End-to-End-Tests an und die klicken ja natürlich durch und kaufen, wie blöd.
Daniel Langemann: Und auf einmal läuft das Ding los und versucht dann irgendwie x Bestellungen zu machen und Fraud Detection schlägt natürlich im Produktivsystem an.
Daniel Langemann: Man sagt so, edgy badg, guck mal, vielleicht sind die Credentials weg und auf einmal funktioniert der Shop nicht.
Daniel Langemann: weil ich lokal natürlich ein Brute Force sozusagen auf das Produktivsystem Payment System gemacht habe.
Daniel Langemann: Also noch nicht passiert, aber ich hätte es einmal fast geschafft.
Daniel Langemann: Also
Daniel Langemann: Genau deswegen möchte ich solche Sachen gar nicht haben, weil dann kann es mir gar nicht passieren, dass ich aus Versehen Bestellungen auslöse oder Kundendaten genauso.
Daniel Langemann: Dann spiele ich im Shop rum, die End-to-End-Tests laufen durch und nehme zum Beispiel den erstbesten Kunden, den die finden, der gerade vor einer Stunde gekauft hat.
Daniel Langemann: Und dann kriegt der einfach mal 50 E-Mails, weil der dann irgendwie Testbestellung 1, 2, 3 kriegt.
Daniel Langemann: Naja, so.
Kai Ole Hartwig: Ja, auch Testbestellungen im Produktivsystem.
Kai Ole Hartwig: Also ich habe da auch so meine Erfahrungen, ich sage jetzt mal, von gelieferten Wein über palettenweise Fliesen und andere Baustoffe habe ich da schon alles erlebt.
Kai Ole Hartwig: Zum Glück war ich ja nie im Shop-Team, also konnte ich das sehr entspannt sehen.
Kai Ole Hartwig: Aber ich sage jetzt mal, es ist schon komisch, wenn da jemand mit so einer Palette auf einmal steht.
Daniel Langemann: Ja.
Daniel Langemann: Also für alle Unbeteiligten immer lustig, aber nicht für den Armen, der es auslöst.
Kai Ole Hartwig: So, und das ist ja einfach so ein Ding.
Kai Ole Hartwig: Und da bin ich auch froh.
Kai Ole Hartwig: In CMS-Systemen haben wir es ja ähnlich, oder wenn ERP-Systeme angebunden sind oder Ähnliches, das Testen wird dann immer schwieriger, weil dann gibt es vielleicht einfach die Systeme nicht dafür.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Und nachher hat man dann doch Produktivdaten auch lokal und schießt dann doch gegen das andere Produktivsystem, was da steht.
Kai Ole Hartwig: Das, finde ich, sind auch immer sehr schwierige Situationen, weil du halt nicht wirklich entspannt arbeiten kannst damit.
Kai Ole Hartwig: Du musst immer sehr, sehr genau aufpassen, was passiert denn jetzt gerade.
Kai Ole Hartwig: Und ich finde, solche Situationen sind gut zu vermeiden.
Daniel Langemann: Ja.
Kai Ole Hartwig: Besser das System sagt mir, ich kann damit gar nicht sprechen, weil ich kenne das nicht, schicke mir einen Fehlercode zurück, dann merke ich wenigstens, ich habe gerade was Dummes gemacht, ohne dass was kaputt gegangen ist.
Kai Ole Hartwig: Und ich glaube, jeder hat schon mal ein Produktivsystem abgeschossen.
Kai Ole Hartwig: Aber ich finde auch diese Änderung quasi zu sagen, okay, ich komme gar nicht mehr auf diese Produktivsysteme drauf.
Kai Ole Hartwig: Und ich lasse zum Beispiel auch entsprechende Datenbank Migrationen in meiner Pipeline laufen.
Kai Ole Hartwig: System, das Deployed, ist auch verantwortlich, dass die Datenbank Migration läuft und solche Dinge.
Kai Ole Hartwig: Ich finde, das war für mich persönlich damals ein gedanklich sehr großer Schritt, da hinzukommen.
Kai Ole Hartwig: Ja, auch nicht mehr dieses Notfall-Backup zu haben mit, ich logge mich jetzt einfach mal auf dieses Produktivsystem ein und dann fixe ich das halt im Zweifelsfall, was da gerade kurz schiefgegangen ist in fünf Minuten.
Kai Ole Hartwig: Ja, also so wirklich, ja, ja, Daniel, ich komme ja aus einer dunklen Welt, wo wir mit FTP deployed haben und auf dem, also, ne, wo es keine Testsysteme gab.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und ich finde, das ist eigentlich auch ein Ding, was man halt verstehen muss.
Kai Ole Hartwig: Man muss halt wirklich lokale Entwicklungsumgebungen, haben wir ja beim letzten Mal darüber gesprochen, haben die,
Kai Ole Hartwig: die sehr nah an dem Produktivsystem sind, damit man alles gut machen kann.
Kai Ole Hartwig: Und dann braucht man und dann macht halt auch aus meiner Sicht ein Secret Management mit einem Volt etc.
Kai Ole Hartwig: Sinn.
Kai Ole Hartwig: Und dann halt nicht nur SOPs.
Kai Ole Hartwig: Also ich mag SOPs, gerade für Entwicklungsumgebungen, dass man auch da ein bisschen sorgsam mit den Sachen umgeht und vielleicht auch so eine Datenbankdamp sich einfach mal an
Kai Ole Hartwig: nur verschlüsselt zum in den Chart legt, damit, falls das mal irgendwie public wird, dann wenn doch mal irgendwelche Daten drin waren, die da vielleicht eigentlich nicht drin sein sollten, dass die auch einfach nicht unverschlüsselt verloren gehen, weil das geht zum Beispiel auch wunderbar mit SOPs.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, du kannst einfach eine Datenbank Dampf verschlüsseln.
Kai Ole Hartwig: Dafür liebe ich das Ding so ein bisschen.
Kai Ole Hartwig: So und ich, also das mag ich grundsätzlich und du kannst damit halt auch deine Key Rotation und so einfach mal sehr flach und einfach testen.
Kai Ole Hartwig: Was passiert denn, wenn ich jetzt einfach den Datenbank Key, das Datenbank Passwort ändere?
Kai Ole Hartwig: Und ich finde dann lokal immer noch ein Roll zu haben zum Testen und da rotiere ich dann und was passiert dann?
Kai Ole Hartwig: Es ist manchmal vielleicht je nach Projekt einfach ein bisschen
Daniel Langemann: Overengineered.
Kai Ole Hartwig: too much overengineered, weil dann muss ich doch wieder irgendwie das Tool besser kennen, das ich vielleicht auch als Entwickler gar nicht so gut kenne.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und da finde ich, sind dann einfache Sachen, die für die Applikation aber am Tagesende gleich aussehen, weil halt über die Runtime einfach das Passwort reingereicht wird.
Kai Ole Hartwig: Aus welchem Tool auch immer, ist ja völlig egal.
Kai Ole Hartwig: an für sich für die Applikation, hoffentlich ist es dir egal, dass man dann halt so hingeht und so auch lokal wirklich alles durchtesten kann.
Kai Ole Hartwig: Ja, nichts ist witziger, als wenn das Datenbankpasswort rotiert wird, aber der Mechanismus einfach nicht gut funktioniert.
Kai Ole Hartwig: In der Applikation steht ein neues Passwort drin, die Datenbank kennt das aber gar nicht.
Daniel Langemann: Musst du den Finger in die Wunde legen?
Kai Ole Hartwig: Natürlich, natürlich.
Kai Ole Hartwig: Aber das ist ja auch so ein, also
Daniel Langemann: Also, ich habe es geschafft.
Kai Ole Hartwig: Ja.
Daniel Langemann: Das ist noch gar nicht so lange her.
Daniel Langemann: Kleines Projekt.
Daniel Langemann: Und auf AWS kannst du das ja sogar, also Setup war halt auch mit RDS-Datenbank und Secrets-Manager.
Daniel Langemann: Ich denke mir, geil, du bist richtig sicher, lässt das Datenbankpasswort rotieren, wir entwickeln fröhlich, fleißig, erster Tag, Live-Gang.
Daniel Langemann: Ich habe die Rotation nicht getestet, weil ich habe nicht aufgepasst, das wurde in einem anderen Secret geschrieben, das neue Passwort.
Daniel Langemann: Mitten im Livebetrieb, also wo du jetzt sagst testen, also kann ich nur bestätigen, sollte man vorher testen.
Daniel Langemann: Das Problem war, ich glaube, ich habe es auf sieben Tage gestellt, wollte es nachher noch testen, habe es nicht mehr getestet, habe es vergessen und es hat natürlich nicht funktioniert.
Kai Ole Hartwig: Ja, Klassiker, ne?
Kai Ole Hartwig: Ganz klassisches Ding.
Kai Ole Hartwig: Das ist ja auch, das ist der Punkt, wo ich sage, man muss was gut überlegen, was man da tut an der Stelle.
Kai Ole Hartwig: Ja, also, vielleicht aus eigener Erfahrung.
Daniel Langemann: Ja, habe ich bewiesen.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Und das sind auch Dinge, definitiv aufschreiben.
Kai Ole Hartwig: Das sind so Teile, erst aufschreiben, dann machen.
Kai Ole Hartwig: Nicht einfach spontan machen, finde ich.
Kai Ole Hartwig: Damit auch jemand anderes nachlesen kann, was ich mir eigentlich gedacht habe.
Kai Ole Hartwig: Was ich als logische Idee empfunden habe.
Kai Ole Hartwig: Oder aus welchem verrückten Blogbeitrag ich irgendeine Idee geklaut habe.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: Und dass man das nachlesen kann, was da eigentlich passieren soll, um das auch abzugleichen.
Daniel Langemann: Mhm.
Daniel Langemann: Gerade auch später, dann ein halbes Jahr oder dreiviertel Jahr später.
Daniel Langemann: Oft ist man ja nicht mehr die gleiche Person im Projekt oder was weiß ich, was ich vor einem halben Jahr gedacht habe nach fünf anderen Projekten.
Daniel Langemann: Gerade wenn die dann so ein bisschen ähnlicher aufgesetzt waren.
Kai Ole Hartwig: Bis wenn es noch das gleiche Projekt ist.
Daniel Langemann: Ja, ja, genau.
Kai Ole Hartwig: Also das ist ja so, also wenn du Sachen nach drei Monaten nochmal anschaust, das hätte auch jemand anderes schreiben können.
Kai Ole Hartwig: Aber manchmal schon nach einer Woche.
Kai Ole Hartwig: Also das geht Blame als immer.
Kai Ole Hartwig: Die Erkenntnis, dass man zu dem Zeitpunkt vielleicht noch nicht so schlau war wie heute.
Kai Ole Hartwig: Welchen Secrets Manager würdest du denn jetzt, wenn das perfekte Setup, was wäre da ein Traum als Secret Management?
Daniel Langemann: Also ich bin einfach als AWS-Fanboy, würde ich jetzt mal sagen.
Daniel Langemann: Also in den letzten Projekten habe ich viel AWS im Setup drin gehabt und mit AWS ECS zum Beispiel, also Docker-Container und Fargate, die automatisch skalieren,
Daniel Langemann: Da bist du natürlich sofort dabei.
Daniel Langemann: AWS Secrets Manager für die Datenbank mit einem rotierenden Passwort und Parameter Store für Parameter kannst du schön einstellen, dass wirklich nur der ECS-Container darauf Zugriff hat.
Daniel Langemann: Also da musst du dir auch nicht Sorgen machen, dass du irgendwie AWS Credentials nochmal irgendwo unterbringen musst auf einem V-Host oder so.
Daniel Langemann: Da bist du schon sehr sicher mit dabei.
Kai Ole Hartwig: Und
Daniel Langemann: In anderen Projekten hatte ich jetzt von Hachikop den Vault Store noch erlebt, also nicht selbst verwaltet, aber erlebt.
Daniel Langemann: Und das ist natürlich auch angenehm, weil da Operations das komplett verwaltet hat.
Daniel Langemann: Also komplett kopiert, Production und für Development gab es auch einen, haben wir da verwaltet, hatten dann unsere lokalen Credentials drin.
Daniel Langemann: Das war ganz gut, weil wir mussten Credentials sozusagen beantragen und das hat dazu geführt, dass wir
Daniel Langemann: nicht nach Production deployen können, weil wir mussten ja für lokal auch schon Credentials beantragen, damit das funktioniert.
Kai Ole Hartwig: Ja.
Daniel Langemann: Genau dieses mit, ich trage das lokal selber ein, also wie mit dem Rotieren auch, man vergisst das nachher zu testen, man vergisst Operations Bescheid zu sagen, deployed off port und es knallt und alle so, warum, es hat doch lokal funktioniert.
Daniel Langemann: Und dann siehst du in den Logs mit, ja guck mal, Credentials fehlen.
Daniel Langemann: Also deswegen war das ganz gut, dass du für lokal auch beantragen musst.
Daniel Langemann: Das hört sich jetzt schlimmer an, als es ist, aber das war so ein Sicherheitsmechanismus.
Daniel Langemann: Und wenn du das hattest, haben die jetzt automatisch auch für Pod schon was erstellt.
Daniel Langemann: Und dann konntest du sicher sein, dass das da ist, wenn du es lokal hattest.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich meine, wenn das ein gut laufender Prozess ist, warum nicht?
Kai Ole Hartwig: Also es spricht ja gar nichts gegen schlanke, gut laufende Prozesse.
Kai Ole Hartwig: Und vor allem, wenn halt auch die Verantwortlichen klar ist.
Kai Ole Hartwig: Wenn klar ist, Operations, Ops ist immer, oder DevOps oder Who Cares, ein Team, egal wie wir es nennen.
Kai Ole Hartwig: ist verantwortlich für Secret Management, dann ist es ja eine ganz klar geregelte Verantwortlichkeit.
Kai Ole Hartwig: Das ist viel cooler, als wenn sich niemand für etwas verantwortlich fühlt.
Daniel Langemann: Ja, aber dann hast du kein Secrets-Problem, dann hast du ein Prozess-Problem.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, natürlich, dann hast du ein ganz anderes Problem.
Kai Ole Hartwig: Aber ich finde bei Secrets und bei solchen Themen...
Kai Ole Hartwig: merkst du das halt am ehesten, dass es Prozessprobleme gibt.
Kai Ole Hartwig: Dadurch, dass die Sachen halt nicht sauber laufen und dass du dann halt stehst und sagst, ach, jetzt, ja gut, ich kann alles einrichten, außer das Produktivsystem.
Kai Ole Hartwig: Im Produktivsystem fehlt jetzt das Secret.
Kai Ole Hartwig: Ja, schade, ich habe aber deployed, weil Deployment darf ich ja.
Kai Ole Hartwig: So, das ist ja das Ding.
Kai Ole Hartwig: Ich finde, da muss man halt klare,
Kai Ole Hartwig: Übergänge schaffen und haben und an solchen Stellen merkt man das immer sehr gut, ob da Verantwortung übernommen wird für etwas und Verantwortlichkeiten geklärt sind oder ob das so ein ist, ja, wir haben das mal gemacht, weil wir haben gehört, das ist gut.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Stell dir vor, jemand geht jetzt hin nach unserem Podcast und sagt, ja, wir verschlüsseln jetzt alle Secrets.
Kai Ole Hartwig: Coole Idee, ja, go for it.
Kai Ole Hartwig: Aber es weiß niemand anderes davon und nur das eine Team macht das und die anderen Teams machen es nicht.
Kai Ole Hartwig: Aber ein anderes Team konsumiert auch die Datenbank-Credentials und kommt auf einmal nicht mehr ran.
Kai Ole Hartwig: Ja, ich habe da verrückte Dinge im Kopf.
Kai Ole Hartwig: So etwas wie, ich habe zwei Teams, gleiche Datenbank und jeder macht, was er möchte.
Kai Ole Hartwig: Das funktioniert natürlich nicht.
Kai Ole Hartwig: Am schlimmsten ist es noch, wenn man gar nicht weiß, dass das andere Team das auch macht.
Kai Ole Hartwig: Oder auf einmal zum Beispiel zwei oder drei Teams sich die Verantwortlichkeit für einen Service teilen.
Daniel Langemann: Ja, beide verschlüsselt.
Kai Ole Hartwig: Da wird es halt schwierig, weil dann muss es eigentlich ein Team sein.
Kai Ole Hartwig: Also dann hat man die Sachen falsch geschnitten.
Daniel Langemann: Also was man nochmal machen kann ist, war halt auch in dem letzten Beispiel auch so, wir haben nachher gesplittet.
Daniel Langemann: Also wir haben wirklich gesagt, was sind Credentials oder Secrets, also Datenbankpasswörter, Zugang fürs Payment und, und, und.
Kai Ole Hartwig: Ja klar.
Daniel Langemann: Und was sind Parameter?
Daniel Langemann: Also im Sinne von...
Daniel Langemann: ich habe einen Feature-Flag irgendwo mit drin und möchte jetzt irgendein tolles Feature an- und ausschalten können.
Daniel Langemann: Das hatten wir da auch zum Beispiel über Umgebungsvariablen gelöst.
Daniel Langemann: Und beides war in einem Secrets-Manager organisiert.
Daniel Langemann: Auf den einen hatte das Entwicklerteam Zugriff, weil ob ein Flag für Feature 1, 2, 3 auf True oder False steht, das kann jeder wissen, das ist kein Betriebsgeheimnis.
Daniel Langemann: Das Schlimmste, was passieren kann, dass ein Feature früher online geht, aber da sind die Entwickler auch für zuständig.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und das hat uns auch geholfen, so Geschwindigkeit aufzunehmen, weil vorher war es so, dass alles da drin war und alles musste an Obds herangetragen werden.
Daniel Langemann: Und dann
Daniel Langemann: hast du natürlich direkt den Unmut.
Daniel Langemann: Also ich war auch sehr genervt davon.
Daniel Langemann: Für jede Kleinigkeit, so könnt ihr da bitte das eintragen?
Daniel Langemann: Ja, okay, nächste Woche müssen wir das umtragen.
Daniel Langemann: Könnt ihr dann um 15 Uhr?
Daniel Langemann: Und das waren aber so ganz normale Sachen, wo du sagst, das ist Aufgabe von einem Entwickler.
Daniel Langemann: Und ich denke mal, ob es sind wir auch sehr auf die Nerven gegangen damit, mit unserer unfreundlichen Art und so, könnt ihr das wieder ändern?
Daniel Langemann: Ach, das wollen wir jetzt doch wieder andersrum.
Daniel Langemann: Und das hat... Ja, genau.
Kai Ole Hartwig: Ja, das soll doch noch wieder raus, kurz, 10 Minuten, das muss raus, Tester hat gesagt, geht nicht.
Kai Ole Hartwig: Ja, aber ganz ehrlich, Parameter, also sowas wie Feature-Flex, habe ich ehrlich gesagt noch nie in Secret Manager geschmissen.
Kai Ole Hartwig: Also da tendiere ich dazu, einfach Umgebungsvariablen zu haben und im Zweifelsfall auch einfach über ein Deployment umstellen zu können.
Daniel Langemann: Okay, also im Hintergrund, wir hatten keinen Einfluss auf das Deployment.
Daniel Langemann: Also Unternehmen groß genug, da hast du natürlich Ops, die sich darum kümmern, um Deployment, alles drum und dran.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und die einzige, in Anführungsstrichen, einzige Möglichkeit oder Einfluss, den wir hatten, war über Secrets.
Daniel Langemann: oder den Secrets Manager, den wir genutzt haben.
Daniel Langemann: Das war sozusagen die Schnittstelle und dementsprechend haben wir dann gesagt, bevor wir jetzt noch das nächste Tool daneben bauen und die Komplexität wieder hochtreiben, lasst uns das nutzen, was wir im Projekt haben, weil ansonsten hätten wir lokal das reproduzieren müssen und sagen müssen, guck mal, wir haben jetzt, weiß ich nicht, also man kann das ja über die.env-Datei, man kann es umgebungsvariablen, man kann es irgendwo im PHP-Kontext unterbringen,
Kai Ole Hartwig: Mhm.
Daniel Langemann: Und nachher hast du dann vier Stellen, wo du Sachen suchen musst.
Daniel Langemann: Und das erhöht natürlich auch direkt wieder die Chance, dass irgendjemand sagt, ich glaube, das ist eine gute Stelle für einen Secret.
Daniel Langemann: Den packe ich da mal rein und teste das.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, natürlich, natürlich.
Kai Ole Hartwig: Ich bin ein großer Fan davon, aber jetzt weichen wir etwas vom Thema ab, auch, dass bis zu einem gewissen Punkt das Deployment in der Verantwortung, also auch die Pipeline in der Verantwortung von einem Entwicklungsteam liegt.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Ja, aber das besprechen wir, glaube ich, irgendwann.
Kai Ole Hartwig: Wann ich denke, dass, oder wo ich denke, dass Dev und Ops so ihre Schnittstelle haben und warum es DevSecOps eigentlich ist.
Daniel Langemann: Ich finde aber das Thema... Also zumindest das Bewusstsein für Credentials.
Daniel Langemann: wo die hingehören, wo die nicht hingehören.
Daniel Langemann: Und gerade auch Pipeline ist auch so ein Thema, was ich auch schon öfter gesehen habe, dass Leute davon ausgehen, dass wenn Docker-Container gebaut werden, dass auch in einer Pipeline gebaut werden, irgendwie sicher sind.
Daniel Langemann: Und dann werden Docker-Container mit Secrets da drin in ein Repository gepusht.
Daniel Langemann: Und das ist so...
Kai Ole Hartwig: Ja, schön.
Kai Ole Hartwig: Ja, vor allem war es ja auch, also da gibt es ja tatsächlich auch noch ganz andere Probleme, wenn du dann, wenn du zum Beispiel irgendeinen privaten Key brauchst, um Sachen zu ziehen, während der Build-Time, dann liegt das nachher in deinem Container drin.
Daniel Langemann: Genau.
Daniel Langemann: Genau.
Kai Ole Hartwig: Ja, also du kannst es anders übergeben, dass es quasi nur zur Runtime kurzzeitig verfügbar war, aber das musst du natürlich wissen.
Kai Ole Hartwig: Also, ähm,
Kai Ole Hartwig: Und Container sind ja per se nicht sicherer als jedes andere System auch.
Kai Ole Hartwig: Du musst sie sicher machen, damit sie sicher sind.
Daniel Langemann: Also jeder Entwickler würde direkt sagen, in den Quelltext würde ich nie einen Frontend, Backend, wie auch immer, einfach so plain Passwörter reinkopieren.
Kai Ole Hartwig: Und
Daniel Langemann: Und das gleiche gilt für Docker-Container auch, weil eigentlich kann man sich das eher wie ein ZIP-Archiv vorstellen, wo auch Sachen drinstehen und Dateien drinliegen.
Daniel Langemann: Und das ist genauso wie Quelltext auch und da darf auch kein Credential drin landen nachher.
Kai Ole Hartwig: Genau, du kannst halt ein Inspect machen, unter anderem, und siehst halt die Sachen, die da passiert sind.
Daniel Langemann: Für viele ist das ja nur eine Blackbox-Container.
Kai Ole Hartwig: So, und, ja, dann kannst du es dir auch sparen, alles, was wir gesagt haben.
Daniel Langemann: Mm.
Kai Ole Hartwig: Was hältst du davon, so etwas wie
Kai Ole Hartwig: One Password oder BitWorden oder so als Secret Manager zu nutzen.
Kai Ole Hartwig: Also quasi dein Passwort Management Tool auch noch im Hosting einzusetzen.
Daniel Langemann: Habe ich mir noch nie Gedanken drüber gemacht.
Daniel Langemann: Also ich habe auch einen Passwort Manager, aber... Das heißt, du installierst ein OnePassword auf einem Server?
Kai Ole Hartwig: Ja, also so als Idee für sehr kleine Setups.
Kai Ole Hartwig: Ja, die CLI.
Kai Ole Hartwig: Dein Gesicht spricht Bände.
Daniel Langemann: Ja, es rattert gerade extrem.
Daniel Langemann: Also ich versuche mal laut zu denken und ich hoffe, ich erzähle nicht zu viel komische Sachen.
Daniel Langemann: Das heißt, ich müsste mich per SSH auf eine Kiste anmelden, installiere die CLI.
Daniel Langemann: Zum Installieren bzw.
Daniel Langemann: um mich einmalig anzumelden, brauche ich die Credentials und dann...
Daniel Langemann: Ist das Ding aktiv, bis der Rechner neu gestartet wird?
Daniel Langemann: Oder werden die, also eine erste Frage wäre, werden die Credentials irgendwo hinterlegt?
Daniel Langemann: Muss ich die?
Kai Ole Hartwig: Gute Frage.
Kai Ole Hartwig: Naja, du musst dich da ja vor allem auch ständig wieder einloggen und anmelden.
Kai Ole Hartwig: Aber ich hatte tatsächlich das als Idee irgendwo jetzt gelesen, die Tage.
Kai Ole Hartwig: dass es schlau wäre, so etwas zu machen quasi, wenn man nicht sagt, ah ja, ich setze hier noch ein neues System auf.
Kai Ole Hartwig: Aber ich finde die Idee halt schwierig, weil genau das sind so diese Fragen, die ich habe.
Kai Ole Hartwig: Rufe ich dann die ganze Zeit bei dem anderen Tool, bei dem anderen Anbieter an und sage, oh, gib mir nochmal, gib mir nochmal, gib mir nochmal.
Kai Ole Hartwig: Dann cache ich es vielleicht doch besser.
Kai Ole Hartwig: Dann läuft irgendwann aber ja meine Session ab.
Kai Ole Hartwig: Das heißt, die muss ich ja auch regelmäßig erneuern.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Also ich habe es bisher nicht gemacht.
Kai Ole Hartwig: Und ich konnte halt auch die Idee nicht so ganz nachvollziehen, weil in meinem Kopf habe ich halt eine Session, also zumindest lokal ist es so, ich habe eine Session, bei der habe ich mich angemeldet und
Kai Ole Hartwig: die läuft halt eine bestimmte Zeit, dann läuft die ab, dann muss ich mich neu anmelden.
Kai Ole Hartwig: Und wenn ich das mache, bedeutet das, ich muss das eigentlich regelmäßig auf dem Server machen und dann halt auch regelmäßig dann die Sachen anfragen.
Kai Ole Hartwig: Oder ich gehe hin und
Kai Ole Hartwig: schreibt dann doch die Daten dann einmal wieder in.end-File oder so.
Kai Ole Hartwig: Aber dann sind wir halt bei dem gleichen Ansatz wie SOPS und ich finde dann ist SOPS irgendwie sympathischer, als wenn ich immer noch zu einem anderen Tool telefonieren muss, weil meine Überlegung ist, was ist denn, wenn dieses Tool eine Störung hat, wenn ich gerade deploye?
Daniel Langemann: Das ist einfach eine weitere Abhängigkeit.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also egal welches Tool, jede externe Schnittstelle kann mal ausfallen.
Daniel Langemann: Man sollte es ja theoretisch so bauen, dass alles ausfallen kann, aber mit Cloudflare und anderen Sachen haben wir gesehen, das funktioniert nicht.
Kai Ole Hartwig: Ja gut, wenn dir das Secret Management ja, wenn dir das Secret Management wegknallt und du keine Secrets mehr kennst, ja, dann
Daniel Langemann: Ich bin gerade noch, also es rattert immer noch in meinem Kopf.
Daniel Langemann: Ich gehe mal davon aus, dass wir das irgendwie hinkriegen, die Credentials oder die Session so sicher zu hinterlegen wie Vault und der Secrets Manager.
Daniel Langemann: Die brauchen auch Credentials.
Daniel Langemann: Also es ist nicht hundertprozentig sicher.
Daniel Langemann: Ich denke mal, da dürfte jetzt kein großer Unterschied sein mit dem Unterschied bei Secrets Manager und anderen.
Daniel Langemann: haben sich klügere Leute als ich Gedanken gemacht, wie man die Sachen ablegt, damit die nicht komplett, also die Credentials oder die Session zum Beispiel ablegt, damit die nicht komplett auf dem Server verfügbar ist.
Daniel Langemann: Bei OnePassword weiß ich nicht.
Daniel Langemann: Also das ist meine Unwissenheit eher.
Daniel Langemann: Also hat sich da schon jemand Gedanken gemacht?
Daniel Langemann: Wurde das so gebaut, dass das so verwendet wird?
Daniel Langemann: Oder ist das einfach so, weil eine API ist und ich habe ein paar Umgebungsvariablen und spreche da was an?
Daniel Langemann: Ja.
Kai Ole Hartwig: Ich habe es mir halt auch nur, ich habe es nur kurz überflogen.
Kai Ole Hartwig: Also es scheint so zu sein, dass es da ein extra Tool für gibt, das ja ähnlich zu funktionieren scheint wie der Volt.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Aber im Detail kann ich das jetzt auch nicht sagen.
Kai Ole Hartwig: Ich dachte, du machst ja auch verrückte Sachen wie ich.
Kai Ole Hartwig: Vielleicht bist du schon darüber gestolpert.
Kai Ole Hartwig: Ich muss sagen, ich finde die Idee halt, ähm,
Kai Ole Hartwig: ein Stück weit, selbst wenn es genauso funktionieren sollte wie der Volt, finde ich es immer ein Stück weit schwierig bei solchen Themen, mich von Services, das gilt auch für AWS im Übrigen, aber für Services abhängig zu machen, die ich nicht selber neu starten kann.
Kai Ole Hartwig: Ja, die ich nicht selber kaputt machen kann, vielleicht auch so ein bisschen.
Kai Ole Hartwig: Also, das mag so ein
Kai Ole Hartwig: mein Ding sein, dass ich sage, wenn man das selber hostet, dann kann man es selber kaputt machen, aber auch selber reparieren.
Daniel Langemann: Ich finde das sympathisch, wenn andere das reparieren müssen und ich das nicht muss.
Kai Ole Hartwig: Und aus irgendeinem Grund finde ich das sympathischer, als wenn ich mich davon abhängig mache, dass jemand anderes das kaputt machen darf und jemand anderes auch reparieren muss.
Daniel Langemann: Also es hängt von der Projektgröße ab.
Daniel Langemann: Bin ich alleine oder bin ich mit zwei Entwicklern da, dann habe ich das ganz gerne gemacht.
Kai Ole Hartwig: Ja, natürlich.
Kai Ole Hartwig: Ja, dann bin ich auch immer froh, wenn ich nichts machen muss von diesen Themen.
Daniel Langemann: Also je kleiner der Bereich einfach ist, um den ich mich kümmern muss, weil, sagen wir mal, wenn du alleine bist, hast du ja so einen Berg mit, ne?
Daniel Langemann: Du hast, sagen wir mal, die Backend, Frontend, du hast Security, du hast Operations und, und, und mit dabei.
Daniel Langemann: Und da bin ich einfach froh, den so klein wie möglich zu halten.
Daniel Langemann: Hast du größere Teams, wo du sagen kannst, ne?
Daniel Langemann: Das ist so ein bisschen dein Steckenpferd.
Daniel Langemann: Du kennst dich in Ops ein bisschen besser aus.
Daniel Langemann: Du hast eine, ne?
Kai Ole Hartwig: Ja, aber das ist ein guter Punkt.
Daniel Langemann: Dann finde ich sowas wieder interessant.
Kai Ole Hartwig: Du kennst dich ein bisschen besser aus, finde ich, ist der Punkt, wo ich sage, da sollte man dann immer noch extern gehen.
Kai Ole Hartwig: Ich finde, das sind so Sachen, da reicht ein bisschen besser auskennen oder habe ich schon mal gesehen.
Kai Ole Hartwig: Es ist quasi der Indikator für mich, wo ich sage, dann sollten wir die andere Lösung benutzen.
Kai Ole Hartwig: Wenn wir jetzt mal bitte, also dieses simple, unflexible Blasops-Gedöns da so ein bisschen ausklammern, weil das ist wirklich einfach und schnell.
Kai Ole Hartwig: Ja, aber wenn man jetzt sich überlegt, ah, ich habe schon mal gesehen, wie ein Volt betrieben wird und jetzt mache ich das überall, finde ich, ist es eine gefährliche Annahme, dann zu sagen, ja, das klappt und ich kann das, das ist gar kein Problem.
Kai Ole Hartwig: Also ich finde, da gehört mehr Erfahrung zu, im Sinne von, vielleicht auch wenn man sagt, wir möchten das gerne machen, das auch einfach ausprobieren und rausfinden.
Daniel Langemann: Also ich meinte, dass... Also ich meinte, dass man die Stufe der bewussten Inkompetenz erreicht hat.
Kai Ole Hartwig: Da möchte ich ja keinem von arbeiten.
Daniel Langemann: Also dass man zumindest weiß, was man alles nicht kann und was es für Probleme geben kann.
Daniel Langemann: Und dann auch beurteilen kann, sagen kann, mach ich nicht, weil kann ich nicht, hab ich nicht genug Ahnung.
Daniel Langemann: Das Schlimmste ist ja,
Daniel Langemann: wenn du keine Ahnung hast, was du alles nicht weißt, dann bist du immer sehr mutig und baust Sachen und merkst dann später erst, was alles schief gehen kann.
Daniel Langemann: Das ist, was du ja gerade beschrieben hast.
Kai Ole Hartwig: Aber wir wissen doch alles.
Kai Ole Hartwig: Wir können doch alles.
Daniel Langemann: Genau.
Daniel Langemann: Ich weiß alles, ich kann alles und ich bin für alles verantwortlich, wenn es kaputt geht.
Kai Ole Hartwig: Ja, sehr schön.
Kai Ole Hartwig: Aber hey, dann ist immerhin jemand da, der verantwortlich ist.
Kai Ole Hartwig: Der hoffentlich dann auch die Verantwortung übernimmt.
Kai Ole Hartwig: Perfekt.
Kai Ole Hartwig: Dann wissen wir jetzt, wir verlieren unsere Secrets, haben sie aber verschlüsselt und deswegen ist das alles nicht mehr so schlimm, weil die sich eh alle sieben Tage erneuern.
Daniel Langemann: Genau.
Kai Ole Hartwig: Perfekt.
Daniel Langemann: Und weil wir es vorher getestet haben, die Rotation.
Daniel Langemann: Und nicht im Produktivsystem.
Daniel Langemann: Ja.
Daniel Langemann: Nee, erstmal nicht.
Kai Ole Hartwig: Na ja, jeder hat halt ein Testsystem.
Daniel Langemann: Der Rest kommt nächste Woche.
Kai Ole Hartwig: Manchmal ist es nicht das Produktivsystem.
Kai Ole Hartwig: Wunderbar.
Kai Ole Hartwig: Dann war es es, glaube ich.
Kai Ole Hartwig: Es sei denn, dir fällt jetzt noch etwas ein, was du unbedingt zu Secrets und Credentials noch loswerden möchtest.
Kai Ole Hartwig: Erstmal nicht.
Kai Ole Hartwig: Nein.
Kai Ole Hartwig: Der Rest kommt nächste Woche.
Kai Ole Hartwig: Perfekt.
Kai Ole Hartwig: Dann war das Folge 2 von Secrets Not Included.
Kai Ole Hartwig: Diesmal mit Secrets.
Kai Ole Hartwig: Und wir freuen uns auf die nächste Folge.
Daniel Langemann: Ja, bis zum nächsten Mal.
Daniel Langemann: Ciao.
Kai Ole Hartwig: Bis dahin.
Kai Ole Hartwig: Ciao.
