Secrets Not Included: Secret Handling

Ja, willkommen zur zweiten Folge Secrets Not Included. Wieder Daniel und Ole hier. Und wir haben uns gedacht, wir sprechen heute mal über Secrets und Geheimnisse. Einfach frei raus, was machen wir da und verraten jetzt doch alle Geheimnisse.

Genau.

Oder Daniel? Ja.

Ja, genau. Alles wird öffentlich, wie es sich nicht gehört. Ne, das passt ja zum Titel. 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. Und dabei ist eigentlich die Abkürzung SOPS gefallen.

Genau.

Und ich habe keinen Plan, was das ist.

SOPS ist eigentlich ein schönes Tool, um Secrets zu verschlüsseln. Also Secrets Operations heißt es. Ist, glaube ich, ursprünglich von Mozilla entwickelt worden und 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.

Achso, das bezeichnet also eine Toolgruppe, so wie ich jetzt AWS Secrets Manager oder Parameter Store, jetzt HashiCorp Vault kenne ich auch.

Genau, das

Das bezeichnet die Toolgruppe also. Okay. Okay.

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

Ja, also basierend auf asynchroner Verschlüsselung. Immer nach dem Konzept, es gibt ein Public und Private Key. Public liegt im Projekt mit drin. Ich kann sagen, ich möchte das Datenpasswort ändern, schreibe es rein, es wird verschlüsselt, im Git abgelegt. 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. Oder?

Umgekehrt, zum Verschlüsseln den Private Key, zum Entschlüsseln den Public Key, oder?

Nein, der sollte ja...

Warte mal, wir müssen das schneiden.

Nein, nein, genau das ist es doch. Also asynchrone Verschlüsselung funktioniert ja in beide Richtungen.

Genau.

Wenn ich den Private Key... Moment, was habe ich jetzt gesagt? Ich habe genau falschrum gesagt, ne? Ich habe die... Ja.

Also du wolltest mit dem Public Key verschlüsseln und mit dem Private Key entschlüsseln.

Ja.

Ich würde gerne mit dem Private Key verschlüsseln und mit dem Public Key entschlüsseln.

Genau so möchte ich das aber, weil nur das Produktivsystem soll ja sehen, welche Passwörter in unserem Git-Repo drin liegen. 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. 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.

Stimmt, du hast absolut recht und ich sollte vielleicht kein Secret Management mit Kopfschmerzen machen. Ja, natürlich, natürlich.

Das haben wir extra eingebaut zum Zeigen und damit ich was erklären kann.

Ja, du hast selbstverständlich an der Stelle recht.

Genau.

Die Secrets sollte man nur entschlüsseln können, wenn man den passenden Key hat. So, das war's, fertig. 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. Vom Grundsatz her möchte man ja eigentlich gar keine Geheimnisse im Git haben. Das geht aber ja explizit und unumstößlich für nicht verschlüsselte Geheimnisse.

Also einfach mit dem Hintergrund, ich möchte zum Beispiel im Produktivsystem das Datenbank-Passwort polieren können. Bei AWS gibt es die Möglichkeit, viele andere machen das auch. 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. 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. Oder zum Beispiel auch Entwickler. Ich als Entwickler muss keine Credentials für irgendwelche Produktivsysteme haben. Ich muss nicht auf Kundendaten zugreifen können, das ist oft auch ein Sicherheitsproblem. Ich darf nicht in der Datenbank suchen können nach Nutzern, die mich nichts angehen. Und oft ist es so in größeren Teams, dass Ops, also Operations, sich um Credentials, um Betrieb kümmert. Da ist protokolliert mit Zugriff und, und, und, wer wann wo wie darauf zugreifen darf. Und ich als Entwickler habe eine Testdatenbank mit unkritischen Daten oder mit irgendwelchen Feature-Daten.

Vielen Dank.

Und kann die dann nacharbeiten und möchte auch gar nicht. 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.

Ja, ich finde, es ist auch immer total schön, Cludentials gar nicht zu kennen. 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.

Ja, genau.

Ja, also ob absichtlich oder unabsichtlich. 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. So.

Lustige Geschichte dazu. 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. 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. Das ist sehr peinlich, aber eine coole Geschichte für Jahre später zum Erzählen. Also...

Ich frage jetzt nicht, wie du auf diese Geschichte kommst und wie der Titel dieses Newsletters zustande gekommen ist.

Ja. Ja, ja. Das wäre mal ein anderes Thema. Oh ja. Ja.

Aber definitiv, wir haben also Dinge, die man nicht hat, kann man nicht verlieren und nicht seltsam benutzen. Ja, wäre nächste Woche dann, übernächste Woche dann das Thema, warum der Newsletter so hieß, wie er hieß? Okay. 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 Secrets halt auch einfach nicht in den produktiven Container gehören, dass sie immer von außen reinkommen sollten. 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.

Mhm.

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. Ja, ich finde das immer total sympathisch, Secrets quasi nur in der Runtime zu haben, in dem Web-Container zum Beispiel, der sie braucht. 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.

Mhm. Yep.

Man hält die halt schön raus und damit macht man halt auch Secret Management einfach. Ja, ich meine, klar, so kannst du halt auch einfach neu deployen, hast neue Secrets drin, alles cool. 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. Bisschen übertrieben, aber rotiere halt alle 30 Tage hier diese Daten und alle x Tage die anderen Daten. 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 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.

Ja, es geht ja auch nicht darum, oh sorry.

So, jetzt muss... Ne, ne, mach ruhig. Da bricht mich.

Es geht ja auch nicht darum, wirklich hundertprozentige Sicherheit, die gibt es nicht. Nichts ist hundertprozentig sicher. Es geht ja nur darum, mit den Maßnahmen es möglichst schwer zu machen. Zum Beispiel an Credentials zu kommen, in Systeme reinzukommen, 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. 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.

Genau.

Aber es ist halt so, die liegen nicht leicht zugänglich. Also das beste Beispiel ist einfach den Schlüssel unter die Fußmatte legen. Das wollen wir nicht. Also es soll eine vernünftige Tür da sein, die Fenster sollen zu sein. Wir wollen den Schlüssel nicht unter die Fußmatte legen, damit derjenige gar nicht, also es nicht leicht hat, ins System zu kommen. Und je mehr man macht, umso besser ist auch oft die Sicherheit. Mhm.

Ich glaube gar nicht je mehr, sondern je durchdachter, finde ich. 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. Also Sachen verstecken, ähm, Hilft ja nicht. Irgendwann findet man, wenn man lang genug sucht und wir können automatisch suchen. Das ist nicht wie, wenn ich den Hausschlüssel finden muss, unter welchem Blumenpott steht. Liegt der jetzt, weil unter der Hausmatte wollte ich ihn ja nicht, sondern das funktioniert ja gleichzeitig und automatisch. Sprich, ich finde, das ganze Secret Management und welche Sicherheitsmaßnahmen man macht, sollte halt durchdacht sein. 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. 80 und von 80 werde ich auf 443 auf HTTPS umgeleitet und dann ist das meine Zugriffsmöglichkeit. 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. Ja, da müsste ich ja einen Weg finden, in diesen Container reinzukommen oder in dieses System reinzukommen und von dort aus weiterzukommen. Klar, wenn ich es geschafft habe, reinzukommen, dann ist es immer noch schön, wenn es, ähm, Maßnahmen gibt es, die dafür sorgen, dass es schwierig ist, drinnen zu bleiben.

Ja.

Oder schwierig ist halt, die Credentials auszulesen, weil man sie halt nicht einfach mit Print Env oder so ausgeben kann. Und das sind ja so diese Schritte, wenn man, ich finde, wenn man so ein paar durchdachte Dinge tut, dann erhöht man halt die Sicherheit auch unfassbar. 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, das erhöht den Aufwand darauf zuzugreifen und die Wahrscheinlichkeit, dass einfach eine Sicherheitslücke ausgenutzt werden kann. Selbst wenn sie drin ist, muss man halt nochmal eine Schippe drauflegen, um sie ausnutzen zu können.

Mhm.

Und ich sage jetzt mal, je mehr Schichten, von so einem Emmentaler mit den großen Löchern du aufeinanderlegst. Je undurchlässiger wird das ja. Wenn du das dann irgendwann hochhältst, siehst du ja auch keine direkte Lücke mehr. Da sind zwar überall Löcher drin, aber die verdecken sich halt gegenseitig und dann kannst du halt nicht durchschauen. Und, ähm, 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. Wir wissen ja eigentlich auch, langlebige Credentials sind halt das höchste Risiko.

Mhm.

Wenn wir so ein API Key nie ändern über ein Jahr oder noch länger, dann geht er halt mit hoher Wahrscheinlichkeit dann doch irgendwann mal verloren. Und da finde ich das total wichtig. Jetzt gehen wir beide natürlich wieder davon aus, dass wir in einer schönen, containerisierten Welt sind, in der wir sowas haben. Ich finde, da ist es deutlich schwieriger mit umzugehen, wenn wir halt auf einem Standard-V-Host-Setup oder Shared-Setup sind.

Ja, ja.

Weil da wird es natürlich sehr, sehr schwierig, das oder schwieriger, entsprechende Maßnahmen zu machen. Einfach weil du dann ja in der Situation bist, alles liegt auf dem gleichen Ding drauf.

Also da bieten sich ja dann von HashiCorp Vault, AWS Parameter Store oder Secrets Manager schon fast an, weil die recht einfach einzubauen sind, 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. 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. Das wäre ja so ein bisschen der Super-GAU. 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. Also zum Beispiel von Symfony gibt es das auch. dass man Secrets verwalten kann. Genau nach diesem Konzept mit Public Key, Private Key. 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. mit wem teilt man sich das? Ist man der alleinige Herrscher auf dem System oder gibt es da andere Abteilungen, die nicht zugreifen sollen? 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.

Vielen Dank.

Ich habe die Kontrolle über den Host, 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 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.

Ja.

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.

Ja, aber ich finde tatsächlich, dieses Secret-Management auf V-Host ist halt sehr schwierig, weil alles ist im gleichen Ding. Irgendwie hat dann doch dieser V-Host-User Zugriff auf alles.

Mhm.

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, die werden da schwierig. Wofür verschlüssel ich irgendwo ein Secret, wenn ich den Key quasi daneben legen muss und jeder kommt da dran? Ich sage jetzt mal für den ungeübten, nicht Linux-affinen Menschen, der da draufkommt, falls es das denn gibt, wäre das sicherlich zumindest, also man sucht zumindest ein bisschen, bis man das entschlüsselt, bis man den Key gefunden hat. Fünf Minuten. Aber, ja, bedeutet halt, es ist zumindest ein Schutz da, dass ein Entwickler die Dinge nicht so einfach verliert. Oder nicht unverschlüsselt verliert.

Um bei unserer Metapher zu bleiben, wir haben einen großen Stein auf die Matte gelegt.

Ja.

Ja.

Ja, immerhin. Immerhin den großen, ne? Aber ich meine, ich finde ja auch Schlüssel im Blumentopf viel sympathischer als eine Löffnungsmatte.

Ja. Aber nicht, wenn es friert. Mhm. Genau.

Das kommt halt drauf an, wo der Topf steht. Oder die Fußmatte. Naja, wenn das schön wettergeschützt ist, ist das vielleicht eine Option.

Ich werde mal bei dir vorbeifahren und gucken. Ja, mache ich. Ja.

Mach das, mach das, bitte. Und wenn du dann vor der Tür stehst, schön lächeln für die Kamera und winken. Gut. Heißt, aber wir beide sind großer Fan davon, Secrets nicht zu kennen, Credentials nicht zu kennen. 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.

Exakt.

Perfekt.

Gerade das Verlieren ist schlimm. Ja, es ist so. Also, dass etwas schief geht, kannst du nie ausschließen. 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...

Ja.

Meistens ist es mit Paymentsachen, es gibt oft keine Testumgebung fürs Payment oder das Testsystem ist irgendwie anders konfiguriert. Ja, natürlich macht man das. 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. 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. Man sagt so, edgy badg, guck mal, vielleicht sind die Credentials weg und auf einmal funktioniert der Shop nicht. weil ich lokal natürlich ein Brute Force sozusagen auf das Produktivsystem Payment System gemacht habe. Also noch nicht passiert, aber ich hätte es einmal fast geschafft. Also 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. 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. Und dann kriegt der einfach mal 50 E-Mails, weil der dann irgendwie Testbestellung 1, 2, 3 kriegt. Naja, so.

Ja, auch Testbestellungen im Produktivsystem. 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. Zum Glück war ich ja nie im Shop-Team, also konnte ich das sehr entspannt sehen. Aber ich sage jetzt mal, es ist schon komisch, wenn da jemand mit so einer Palette auf einmal steht.

Ja. Also für alle Unbeteiligten immer lustig, aber nicht für den Armen, der es auslöst.

So, und das ist ja einfach so ein Ding. Und da bin ich auch froh. 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. Und Und nachher hat man dann doch Produktivdaten auch lokal und schießt dann doch gegen das andere Produktivsystem, was da steht. Das, finde ich, sind auch immer sehr schwierige Situationen, weil du halt nicht wirklich entspannt arbeiten kannst damit. Du musst immer sehr, sehr genau aufpassen, was passiert denn jetzt gerade. Und ich finde, solche Situationen sind gut zu vermeiden.

Ja.

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. Und ich glaube, jeder hat schon mal ein Produktivsystem abgeschossen. Aber ich finde auch diese Änderung quasi zu sagen, okay, ich komme gar nicht mehr auf diese Produktivsysteme drauf. Und ich lasse zum Beispiel auch entsprechende Datenbank Migrationen in meiner Pipeline laufen. System, das Deployed, ist auch verantwortlich, dass die Datenbank Migration läuft und solche Dinge. Ich finde, das war für mich persönlich damals ein gedanklich sehr großer Schritt, da hinzukommen. 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. 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.

Ja.

Und ich finde, das ist eigentlich auch ein Ding, was man halt verstehen muss. Man muss halt wirklich lokale Entwicklungsumgebungen, haben wir ja beim letzten Mal darüber gesprochen, haben die, die sehr nah an dem Produktivsystem sind, damit man alles gut machen kann. Und dann braucht man und dann macht halt auch aus meiner Sicht ein Secret Management mit einem Volt etc. Sinn. Und dann halt nicht nur SOPs. 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 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.

Ja.

Ja, du kannst einfach eine Datenbank Dampf verschlüsseln. Dafür liebe ich das Ding so ein bisschen. 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. Was passiert denn, wenn ich jetzt einfach den Datenbank Key, das Datenbank Passwort ändere? Und ich finde dann lokal immer noch ein Roll zu haben zum Testen und da rotiere ich dann und was passiert dann? Es ist manchmal vielleicht je nach Projekt einfach ein bisschen

Overengineered.

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.

Mhm.

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. Aus welchem Tool auch immer, ist ja völlig egal. 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. Ja, nichts ist witziger, als wenn das Datenbankpasswort rotiert wird, aber der Mechanismus einfach nicht gut funktioniert. In der Applikation steht ein neues Passwort drin, die Datenbank kennt das aber gar nicht.

Musst du den Finger in die Wunde legen?

Natürlich, natürlich. Aber das ist ja auch so ein, also

Also, ich habe es geschafft.

Ja.

Das ist noch gar nicht so lange her. Kleines Projekt. Und auf AWS kannst du das ja sogar, also Setup war halt auch mit RDS-Datenbank und Secrets-Manager. Ich denke mir, geil, du bist richtig sicher, lässt das Datenbankpasswort rotieren, wir entwickeln fröhlich, fleißig, erster Tag, Live-Gang. Ich habe die Rotation nicht getestet, weil ich habe nicht aufgepasst, das wurde in einem anderen Secret geschrieben, das neue Passwort. Mitten im Livebetrieb, also wo du jetzt sagst testen, also kann ich nur bestätigen, sollte man vorher testen. 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.

Ja, Klassiker, ne? Ganz klassisches Ding. Das ist ja auch, das ist der Punkt, wo ich sage, man muss was gut überlegen, was man da tut an der Stelle. Ja, also, vielleicht aus eigener Erfahrung.

Ja, habe ich bewiesen.

Ja. Und das sind auch Dinge, definitiv aufschreiben. Das sind so Teile, erst aufschreiben, dann machen. Nicht einfach spontan machen, finde ich. Damit auch jemand anderes nachlesen kann, was ich mir eigentlich gedacht habe. Was ich als logische Idee empfunden habe. Oder aus welchem verrückten Blogbeitrag ich irgendeine Idee geklaut habe. Ähm... Und dass man das nachlesen kann, was da eigentlich passieren soll, um das auch abzugleichen.

Mhm. Gerade auch später, dann ein halbes Jahr oder dreiviertel Jahr später. 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. Gerade wenn die dann so ein bisschen ähnlicher aufgesetzt waren.

Bis wenn es noch das gleiche Projekt ist.

Ja, ja, genau.

Also das ist ja so, also wenn du Sachen nach drei Monaten nochmal anschaust, das hätte auch jemand anderes schreiben können. Aber manchmal schon nach einer Woche. Also das geht Blame als immer. Die Erkenntnis, dass man zu dem Zeitpunkt vielleicht noch nicht so schlau war wie heute. Welchen Secrets Manager würdest du denn jetzt, wenn das perfekte Setup, was wäre da ein Traum als Secret Management?

Also ich bin einfach als AWS-Fanboy, würde ich jetzt mal sagen. 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, Da bist du natürlich sofort dabei. 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. Also da musst du dir auch nicht Sorgen machen, dass du irgendwie AWS Credentials nochmal irgendwo unterbringen musst auf einem V-Host oder so. Da bist du schon sehr sicher mit dabei.

Und

In anderen Projekten hatte ich jetzt von Hachikop den Vault Store noch erlebt, also nicht selbst verwaltet, aber erlebt. Und das ist natürlich auch angenehm, weil da Operations das komplett verwaltet hat. Also komplett kopiert, Production und für Development gab es auch einen, haben wir da verwaltet, hatten dann unsere lokalen Credentials drin. Das war ganz gut, weil wir mussten Credentials sozusagen beantragen und das hat dazu geführt, dass wir nicht nach Production deployen können, weil wir mussten ja für lokal auch schon Credentials beantragen, damit das funktioniert.

Ja.

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. Und dann siehst du in den Logs mit, ja guck mal, Credentials fehlen. Also deswegen war das ganz gut, dass du für lokal auch beantragen musst. Das hört sich jetzt schlimmer an, als es ist, aber das war so ein Sicherheitsmechanismus. Und wenn du das hattest, haben die jetzt automatisch auch für Pod schon was erstellt. Und dann konntest du sicher sein, dass das da ist, wenn du es lokal hattest. Mhm.

Ich meine, wenn das ein gut laufender Prozess ist, warum nicht? Also es spricht ja gar nichts gegen schlanke, gut laufende Prozesse. Und vor allem, wenn halt auch die Verantwortlichen klar ist. Wenn klar ist, Operations, Ops ist immer, oder DevOps oder Who Cares, ein Team, egal wie wir es nennen. ist verantwortlich für Secret Management, dann ist es ja eine ganz klar geregelte Verantwortlichkeit. Das ist viel cooler, als wenn sich niemand für etwas verantwortlich fühlt.

Ja, aber dann hast du kein Secrets-Problem, dann hast du ein Prozess-Problem. Ja.

Ja, natürlich, dann hast du ein ganz anderes Problem. Aber ich finde bei Secrets und bei solchen Themen... merkst du das halt am ehesten, dass es Prozessprobleme gibt. 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. Im Produktivsystem fehlt jetzt das Secret. Ja, schade, ich habe aber deployed, weil Deployment darf ich ja. So, das ist ja das Ding. Ich finde, da muss man halt klare, Ü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.

Mhm. Mhm.

Stell dir vor, jemand geht jetzt hin nach unserem Podcast und sagt, ja, wir verschlüsseln jetzt alle Secrets. Coole Idee, ja, go for it. Aber es weiß niemand anderes davon und nur das eine Team macht das und die anderen Teams machen es nicht. Aber ein anderes Team konsumiert auch die Datenbank-Credentials und kommt auf einmal nicht mehr ran. Ja, ich habe da verrückte Dinge im Kopf. So etwas wie, ich habe zwei Teams, gleiche Datenbank und jeder macht, was er möchte. Das funktioniert natürlich nicht. Am schlimmsten ist es noch, wenn man gar nicht weiß, dass das andere Team das auch macht. Oder auf einmal zum Beispiel zwei oder drei Teams sich die Verantwortlichkeit für einen Service teilen.

Ja, beide verschlüsselt.

Da wird es halt schwierig, weil dann muss es eigentlich ein Team sein. Also dann hat man die Sachen falsch geschnitten.

Also was man nochmal machen kann ist, war halt auch in dem letzten Beispiel auch so, wir haben nachher gesplittet. Also wir haben wirklich gesagt, was sind Credentials oder Secrets, also Datenbankpasswörter, Zugang fürs Payment und, und, und.

Ja klar.

Und was sind Parameter? Also im Sinne von... ich habe einen Feature-Flag irgendwo mit drin und möchte jetzt irgendein tolles Feature an- und ausschalten können. Das hatten wir da auch zum Beispiel über Umgebungsvariablen gelöst. Und beides war in einem Secrets-Manager organisiert. 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. Das Schlimmste, was passieren kann, dass ein Feature früher online geht, aber da sind die Entwickler auch für zuständig.

Ja.

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. Und dann hast du natürlich direkt den Unmut. Also ich war auch sehr genervt davon. Für jede Kleinigkeit, so könnt ihr da bitte das eintragen? Ja, okay, nächste Woche müssen wir das umtragen. Könnt ihr dann um 15 Uhr? Und das waren aber so ganz normale Sachen, wo du sagst, das ist Aufgabe von einem Entwickler. 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? Ach, das wollen wir jetzt doch wieder andersrum. Und das hat... Ja, genau.

Ja, das soll doch noch wieder raus, kurz, 10 Minuten, das muss raus, Tester hat gesagt, geht nicht. Ja, aber ganz ehrlich, Parameter, also sowas wie Feature-Flex, habe ich ehrlich gesagt noch nie in Secret Manager geschmissen. Also da tendiere ich dazu, einfach Umgebungsvariablen zu haben und im Zweifelsfall auch einfach über ein Deployment umstellen zu können.

Okay, also im Hintergrund, wir hatten keinen Einfluss auf das Deployment. Also Unternehmen groß genug, da hast du natürlich Ops, die sich darum kümmern, um Deployment, alles drum und dran.

Ja.

Und die einzige, in Anführungsstrichen, einzige Möglichkeit oder Einfluss, den wir hatten, war über Secrets. oder den Secrets Manager, den wir genutzt haben. 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,

Mhm.

Und nachher hast du dann vier Stellen, wo du Sachen suchen musst. 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. Den packe ich da mal rein und teste das. Ja.

Ja, natürlich, natürlich. 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. Ähm. Ja, aber das besprechen wir, glaube ich, irgendwann. Wann ich denke, dass, oder wo ich denke, dass Dev und Ops so ihre Schnittstelle haben und warum es DevSecOps eigentlich ist.

Ich finde aber das Thema... Also zumindest das Bewusstsein für Credentials. wo die hingehören, wo die nicht hingehören. 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. Und dann werden Docker-Container mit Secrets da drin in ein Repository gepusht. Und das ist so...

Ja, schön. 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.

Genau. Genau.

Ja, also du kannst es anders übergeben, dass es quasi nur zur Runtime kurzzeitig verfügbar war, aber das musst du natürlich wissen. Also, ähm, Und Container sind ja per se nicht sicherer als jedes andere System auch. Du musst sie sicher machen, damit sie sicher sind.

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.

Und

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. Und das ist genauso wie Quelltext auch und da darf auch kein Credential drin landen nachher.

Genau, du kannst halt ein Inspect machen, unter anderem, und siehst halt die Sachen, die da passiert sind.

Für viele ist das ja nur eine Blackbox-Container.

So, und, ja, dann kannst du es dir auch sparen, alles, was wir gesagt haben.

Mm.

Was hältst du davon, so etwas wie One Password oder BitWorden oder so als Secret Manager zu nutzen. Also quasi dein Passwort Management Tool auch noch im Hosting einzusetzen.

Habe ich mir noch nie Gedanken drüber gemacht. Also ich habe auch einen Passwort Manager, aber... Das heißt, du installierst ein OnePassword auf einem Server?

Ja, also so als Idee für sehr kleine Setups. Ja, die CLI. Dein Gesicht spricht Bände.

Ja, es rattert gerade extrem. Also ich versuche mal laut zu denken und ich hoffe, ich erzähle nicht zu viel komische Sachen. Das heißt, ich müsste mich per SSH auf eine Kiste anmelden, installiere die CLI. Zum Installieren bzw. um mich einmalig anzumelden, brauche ich die Credentials und dann... Ist das Ding aktiv, bis der Rechner neu gestartet wird? Oder werden die, also eine erste Frage wäre, werden die Credentials irgendwo hinterlegt? Muss ich die?

Gute Frage. Naja, du musst dich da ja vor allem auch ständig wieder einloggen und anmelden. Aber ich hatte tatsächlich das als Idee irgendwo jetzt gelesen, die Tage. dass es schlau wäre, so etwas zu machen quasi, wenn man nicht sagt, ah ja, ich setze hier noch ein neues System auf. Aber ich finde die Idee halt schwierig, weil genau das sind so diese Fragen, die ich habe. 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. Dann cache ich es vielleicht doch besser. Dann läuft irgendwann aber ja meine Session ab. Das heißt, die muss ich ja auch regelmäßig erneuern. Und Also ich habe es bisher nicht gemacht. 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 die läuft halt eine bestimmte Zeit, dann läuft die ab, dann muss ich mich neu anmelden. 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. Oder ich gehe hin und schreibt dann doch die Daten dann einmal wieder in.end-File oder so. 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?

Das ist einfach eine weitere Abhängigkeit.

Ja.

Also egal welches Tool, jede externe Schnittstelle kann mal ausfallen. Man sollte es ja theoretisch so bauen, dass alles ausfallen kann, aber mit Cloudflare und anderen Sachen haben wir gesehen, das funktioniert nicht.

Ja gut, wenn dir das Secret Management ja, wenn dir das Secret Management wegknallt und du keine Secrets mehr kennst, ja, dann

Ich bin gerade noch, also es rattert immer noch in meinem Kopf. 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. Die brauchen auch Credentials. Also es ist nicht hundertprozentig sicher. Ich denke mal, da dürfte jetzt kein großer Unterschied sein mit dem Unterschied bei Secrets Manager und anderen. 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. Bei OnePassword weiß ich nicht. Also das ist meine Unwissenheit eher. Also hat sich da schon jemand Gedanken gemacht? Wurde das so gebaut, dass das so verwendet wird? Oder ist das einfach so, weil eine API ist und ich habe ein paar Umgebungsvariablen und spreche da was an? Ja.

Ich habe es mir halt auch nur, ich habe es nur kurz überflogen. Also es scheint so zu sein, dass es da ein extra Tool für gibt, das ja ähnlich zu funktionieren scheint wie der Volt.

Mhm.

Aber im Detail kann ich das jetzt auch nicht sagen. Ich dachte, du machst ja auch verrückte Sachen wie ich. Vielleicht bist du schon darüber gestolpert. Ich muss sagen, ich finde die Idee halt, ähm, 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. Ja, die ich nicht selber kaputt machen kann, vielleicht auch so ein bisschen. Also, das mag so ein mein Ding sein, dass ich sage, wenn man das selber hostet, dann kann man es selber kaputt machen, aber auch selber reparieren.

Ich finde das sympathisch, wenn andere das reparieren müssen und ich das nicht muss.

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.

Also es hängt von der Projektgröße ab. Bin ich alleine oder bin ich mit zwei Entwicklern da, dann habe ich das ganz gerne gemacht.

Ja, natürlich. Ja, dann bin ich auch immer froh, wenn ich nichts machen muss von diesen Themen.

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? Du hast, sagen wir mal, die Backend, Frontend, du hast Security, du hast Operations und, und, und mit dabei. Und da bin ich einfach froh, den so klein wie möglich zu halten. Hast du größere Teams, wo du sagen kannst, ne? Das ist so ein bisschen dein Steckenpferd. Du kennst dich in Ops ein bisschen besser aus. Du hast eine, ne?

Ja, aber das ist ein guter Punkt.

Dann finde ich sowas wieder interessant.

Du kennst dich ein bisschen besser aus, finde ich, ist der Punkt, wo ich sage, da sollte man dann immer noch extern gehen. Ich finde, das sind so Sachen, da reicht ein bisschen besser auskennen oder habe ich schon mal gesehen. Es ist quasi der Indikator für mich, wo ich sage, dann sollten wir die andere Lösung benutzen. Wenn wir jetzt mal bitte, also dieses simple, unflexible Blasops-Gedöns da so ein bisschen ausklammern, weil das ist wirklich einfach und schnell. 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. 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.

Also ich meinte, dass... Also ich meinte, dass man die Stufe der bewussten Inkompetenz erreicht hat.

Da möchte ich ja keinem von arbeiten.

Also dass man zumindest weiß, was man alles nicht kann und was es für Probleme geben kann. Und dann auch beurteilen kann, sagen kann, mach ich nicht, weil kann ich nicht, hab ich nicht genug Ahnung. Das Schlimmste ist ja, 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. Das ist, was du ja gerade beschrieben hast.

Aber wir wissen doch alles. Wir können doch alles.

Genau. Ich weiß alles, ich kann alles und ich bin für alles verantwortlich, wenn es kaputt geht.

Ja, sehr schön. Aber hey, dann ist immerhin jemand da, der verantwortlich ist. Der hoffentlich dann auch die Verantwortung übernimmt. Perfekt. 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.

Genau.

Perfekt.

Und weil wir es vorher getestet haben, die Rotation. Und nicht im Produktivsystem. Ja. Nee, erstmal nicht.

Na ja, jeder hat halt ein Testsystem.

Der Rest kommt nächste Woche.

Manchmal ist es nicht das Produktivsystem. Wunderbar. Dann war es es, glaube ich. Es sei denn, dir fällt jetzt noch etwas ein, was du unbedingt zu Secrets und Credentials noch loswerden möchtest. Erstmal nicht. Nein. Der Rest kommt nächste Woche. Perfekt. Dann war das Folge 2 von Secrets Not Included. Diesmal mit Secrets. Und wir freuen uns auf die nächste Folge.

Ja, bis zum nächsten Mal. Ciao.

Bis dahin. Ciao.