Transcript
Kai Ole Hartwig: Willkommen zu einer neuen Folge der neunten Folge Secrets Not Included in dieser Woche wieder mit Daniel und Ole und wir möchten uns heute mal über Pipeline Security austauschen, was so in CI-CD abgeht und was man dort eigentlich beachten sollte, damit diese Pipelines auch mal sicher sind.
Kai Ole Hartwig: Daniel, magst du loslegen?
Daniel Langemann: Ich glaube, das ist eher deine Stärke, das Thema.
Daniel Langemann: Aber wir können anfangen mit dem allseits nervigen Thema Security, also Secrets in Pipelines.
Daniel Langemann: Das, was eigentlich so den Entwicklern meistens auf den Füßen liegt, ist,
Daniel Langemann: wenn man eine Pipeline gebaut hat oder deployen möchte, möchte man Tests ausführen.
Daniel Langemann: Oft gibt es auch Testsysteme, die Secrets brauchen oder es gibt andere Services, die getestet werden, wogegen getestet wird.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Und damit das funktioniert, braucht man dafür Secrets in der Pipeline.
Daniel Langemann: Und wie diese da reinkommen und
Daniel Langemann: wie diese genutzt werden und welche Rechte auch in der Pipeline da vorherrschen, damit man Systeme und Tests ausführen kann.
Daniel Langemann: Das ist, glaube ich, ein sehr nerviges Thema.
Daniel Langemann: Also, weil die Entwicklung und Ops da immer...
Daniel Langemann: konträr gegeneinander überstehen.
Daniel Langemann: Die einen wollen natürlich möglichst alles testen und brauchen alle Credentials und Zugriff auf alle Systeme.
Daniel Langemann: Und OBS versucht natürlich so den Blast Radius so möglichst klein zu halten, damit möglichst wenig Zugriffe irgendwie oder Credentials auch in der Pipeline irgendwo rumfliegen.
Daniel Langemann: Weil meistens ist das ja auch dann
Kai Ole Hartwig: Ähm, ehrlicherweise bin ich ja der radikalen Meinung, ähm, die Credentials für Test, Port, whatever, brauchst du nicht wissen.
Kai Ole Hartwig: Also, weder du als Entwickler, noch als Ops, noch als Pipeline oder CI-System.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: Warum behaupte ich das?
Kai Ole Hartwig: Es ist vielleicht die spannendste Frage.
Kai Ole Hartwig: Also erstmal langlebige Secrets irgendwo rumfliegen lassen ist immer eine total beschissene Idee.
Kai Ole Hartwig: Und ich bin auch der Meinung und der Überzeugung, wenn die Pipeline sich irgendwo anmelden muss, muss sie das mit einem eigenen Job spezifischen Token machen.
Kai Ole Hartwig: GitLab CI hat das zum Beispiel gelöst.
Kai Ole Hartwig: Da bekommst du ein Token-
Kai Ole Hartwig: der für diesen Job gerade gültig ist und danach nicht mehr gültig ist.
Kai Ole Hartwig: Damit kannst du dich an allen wichtigen Dingen anmelden.
Kai Ole Hartwig: Bei Registry, also sowohl für die Images als auch bei den Package Registries.
Kai Ole Hartwig: Sprich, du kannst Images ziehen, bauen, pushen.
Kai Ole Hartwig: Du kannst Pakete ziehen, bauen, pushen.
Kai Ole Hartwig: Und damit ist ja eigentlich alles geschafft, was du möchtest, was du ja eigentlich in einer CI-CD-Pipeline haben möchtest, ist, wenn wir mal am Anfang anfangen, du pushst das Zeugs dahin
Kai Ole Hartwig: was du gebaut hast oder nein, du pushst nicht in die Pipeline, du pushst in das Repository und die Pipeline wird dadurch getriggert, dass dort hoffentlich auf einem neuen Feature-Branch im Übrigen Neuer Code angekommen ist.
Kai Ole Hartwig: Dann läuft die Pipeline los und fängt mit den Tests an oder der Prüfung, die am schnellsten läuft, ja, Syntaxfehler und so weiter und so fort.
Daniel Langemann: Vielen Dank.
Kai Ole Hartwig: Dafür brauchst du keine Credentials, dafür musst du eigentlich gar nichts wissen, also was sicherheitsrelevant ist.
Kai Ole Hartwig: dann läufst du ja immer weiter zu den länger laufenden Tests und irgendwann kommst du, glaube ich, an die Testart an, die du meinst, nämlich so etwas wie Functional Tests oder End-to-End Tests, die in irgendeiner Art und Weise mehr benötigen als den statischen Code.
Daniel Langemann: oder Smoketests nach dem Deployment, um zu verifizieren, dass das System noch, also grundlegendst läuft.
Kai Ole Hartwig: Und ja, genau.
Daniel Langemann: Und da brauchst du dann oft reale Credentials, leider.
Kai Ole Hartwig: Ja, das kommt jetzt auf die Infrastruktur an, sage ich.
Kai Ole Hartwig: Wenn du möchtest, dass keine dieser Credentials irgendwie in der Pipeline liegen, ich meine, wir haben das früher auch gemacht, wir haben zum Beispiel.endfights mal irgendwann da reingeschrieben oder auch PHP-Dateien da in der CI-Pipeline aus dem, naja, irgendwo hergeholt, vielleicht aus Variablen,
Kai Ole Hartwig: als es das alles noch nicht so gab und so verbrettet war, aus Variablen halt dann in der PHP-Datei geschrieben, später in der Enddatei, dann waren aus dem 1Password-Zili haben wir, glaube ich, auch mal die Credentials holt und dann so da reingeschrieben.
Kai Ole Hartwig: Das ist aber alles keine gute Idee, wenn man das sich überlegt.
Kai Ole Hartwig: Ja,
Kai Ole Hartwig: weil dann hast du zumindest mal irgendwo langlebige Credentials liegen, um an die Credentials zu kommen und das ist alles irgendwie nicht cool.
Kai Ole Hartwig: Weil Credentials selbst für Datenbankzugriff und so gehören in die Runtime, nicht in irgendein Image reingebaut oder so.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Deswegen ist der Prozess, den ich bevorzuge, um die Pipeline sicher zu haben, ist möglich,
Kai Ole Hartwig: Wir laufen alles durch, dass wir wissen an statischen Analysen, okay, der Code würde vermutlich laufen.
Kai Ole Hartwig: Also nach statischen Gesichtspunkten sieht das gut aus.
Kai Ole Hartwig: Dann bauen wir ein Image.
Kai Ole Hartwig: Das taggen wir definitiv als Testing.
Kai Ole Hartwig: Also nicht Produktionsgreif, sondern man sieht, das ist einfach Alphabeta-whatever.
Kai Ole Hartwig: pushen das in die Image-Registry und ziehen uns das auf ein Testsystem dann runter.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und dann, wenn das da deployed ist,
Kai Ole Hartwig: dann läuft letztendlich eine weitere Pipeline oder die gleiche, wartet, whatever, was auch immer, wie man das jetzt ausmalt, ob man dann aktiv aufs Testsystem pusht quasi oder ob man darauf wartet, dass irgendwie ein Watchtower oder so das zieht.
Kai Ole Hartwig: Jetzt eine Million Varianten gefühlt.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: also egal ob jetzt Push oder Pull, dann läuft die Pipeline weiter und führt dann diese Smoke-Tests etc.
Kai Ole Hartwig: durch oder auch Chaos-Tests.
Kai Ole Hartwig: Einfach mal Services wegschießen in so einem Cluster und schauen, was passiert.
Daniel Langemann: Oh ja.
Kai Ole Hartwig: Aber alle Tests, die laufen sollten, laufen dann gegen ein Testsystem, das alles hat, das aber auch
Kai Ole Hartwig: im Idealfall zum Beispiel einen gewissen Datenbankstand deployed bekommen hat, wenn ich da Abhängigkeiten drin habe.
Kai Ole Hartwig: Ich sage jetzt mal, in CMS-Systemen gibt es ja immer wieder den Mix aus der Herausforderung.
Kai Ole Hartwig: Eigentlich wollen wir möglichst aktuell gegen Produktivdaten testen, aber auf der anderen Seite müssen wir auch Funktionen testen.
Kai Ole Hartwig: Heißt, wir testen
Daniel Langemann: Gerade neue Funktionen zum Beispiel, die noch gar nicht auf dem Produktivsystem sind, kannst du so gar nicht testen meistens.
Daniel Langemann: Hm.
Kai Ole Hartwig: Genau, das heißt wir, oder halt auch alte Funktionen, die jetzt nicht mehr auf dem Produktivsystem zum Beispiel sichtbar sind, irgendeine Slider-Funktion, die mal mega wichtig war natürlich zu bauen und
Kai Ole Hartwig: ganz dringend benötigt war.
Kai Ole Hartwig: Aber jetzt, dann war die zwei Wochen online, da hat man fast gesagt, brauchen wir doch gar nicht.
Kai Ole Hartwig: Aber sie muss ja weiter funktionieren.
Kai Ole Hartwig: Also testest du sie ja in den Testfällen weiter.
Kai Ole Hartwig: Außer es gibt die Entscheidung, wir bauen es dann auch wieder aus.
Kai Ole Hartwig: Die fällt ja nicht so häufig.
Kai Ole Hartwig: Also sprich, das ist ja die Herausforderung bei der Art von Tests.
Daniel Langemann: Vielen Dank.
Kai Ole Hartwig: Und heißt, du fährst dann ja letztendlich eine gewisse Datenbank mit gewissen Fictures hoch, gegen die testest du.
Kai Ole Hartwig: Und das ist aus meiner Sicht auf einem Testsystem, das hochgefahren wird für genau diesen Zweck, mit genau diesem Branch und dann halt läuft.
Kai Ole Hartwig: Und das ist nämlich genau der Punkt.
Kai Ole Hartwig: Dann habe ich nämlich in dem Testsystem wieder meinen ganz normalen Mechanismus, wie komme ich an diese Credentials.
Kai Ole Hartwig: und habe in der Pipeline letztendlich nichts damit zu tun, außer dass ich vielleicht der Pipeline mitgebe, hey, da muss jetzt dieser Datenbank-Dump im weitesten Sinne, diese Datenbank-Daten sollen in die Datenbank geschrieben werden.
Daniel Langemann: Also das setzt aber voraus, dass du das Produktivsystem von der Infrastruktur wirklich eins zu eins kopieren kannst.
Daniel Langemann: Also dass du eine Testdatenbank, also im Idealfall sogar vielleicht eine Kopie machen kannst von einer Produktivdatenbank, irgendwie Daten anonymisieren.
Daniel Langemann: Einfach mal so am Rande erwähnt, macht man natürlich eine
Daniel Langemann: Nicht einfach Nutzerdaten von A nach B schieben, so mit Kreditkarteninfos und sowas, aber du hast eine anonymisierte Produktivdatenbank, du kannst andere Systeme kopieren, dann funktioniert sowas super.
Kai Ole Hartwig: Ja, definitiv.
Daniel Langemann: Es gibt aber immer wieder Ausnahmen, die du nicht kopieren kannst.
Daniel Langemann: Also gerade so im E-Commerce-Bereich Payment.
Daniel Langemann: Du kannst, also so reich kannst du nicht sein, dass du automatisiert mit deiner eigenen Kreditkarte oder Tests durchlaufen lässt.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Deswegen
Kai Ole Hartwig: Genau, es gibt da Gänzen.
Kai Ole Hartwig: Ich sage nicht, das ist die ideale Welt, damit kannst du alle Testfälle abdecken.
Daniel Langemann: Nein, nein.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also worauf ich hinaus wollte, ist, man kann unterscheiden zwischen lesenden und schreibenden Tests.
Daniel Langemann: Also gerade bei Smoke-Tests sage ich immer, es gibt lesende Tests, die sich einfach durch die Applikation durchklicken und so wie ein Benutzer so ein bisschen streunen, sage ich mal, und einfach so ein paar Klickstrecken nachgehen und erwarten, dass keine Fehlermeldungen da sind oder Überschriften irgendwo auftauchen, Titel und sowas.
Daniel Langemann: Und es gibt schreibende Tests, die sind spezieller,
Daniel Langemann: Also in deinem Setup, so wie du es beschrieben hast, wenn du das kopieren kannst oder einen Großteil kopieren kannst, ist das super, weil dann kannst du auch schreibende Tests machen.
Daniel Langemann: Dann kannst du Nutzer anlegen, du kannst Nutzer löschen, also auch solche Tests machen.
Kai Ole Hartwig: Genau, bis halt auf das, was gegen Drittanbieter Zeugs läuft.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und mit Drittanbieter meine ich manchmal auch das Team, was nebenan am TÜV sitzt.
Kai Ole Hartwig: Also du kannst halt in dieser Art von Testumgebung, die halt aus Security-Sicht für die Pipeline bedeutet, die Pipeline kennt keine Credentials und braucht keine Credentials außer den eigenen Job-Token,
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: kannst du dann natürlich für deinen Teil der Applikation oder für die Applikation, die du betreust, beliebige Dinge machen.
Kai Ole Hartwig: Wenn du jetzt mit anderen Services reden musst, die anderen Menschen gehören, anderen Teams gehören, dann bist du natürlich in der Situation drin, da ist halt die Grenze, aber da ist ja auch so eine Verantwortungsgrenze.
Kai Ole Hartwig: Also es ist jetzt ja nicht so, dass sich jeden Tag die vereinbarten Schnittstellen verändern.
Kai Ole Hartwig: Zum Glück nicht.
Daniel Langemann: Nicht täglich, aber das reicht einmal.
Kai Ole Hartwig: Hoffentlich nicht.
Daniel Langemann: Aber...
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Aber das ist ja auch das, wo... Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also das beschriebene Problem löst man ja auch anders.
Daniel Langemann: Also jetzt zum Beispiel das mit dem Payment-Anbieter kannst du anders lösen.
Daniel Langemann: Es gibt extra Monitoring und da baust du zum Beispiel was ein, was das wenn nach einem Deployment, weiß ich nicht, 30 Minuten lang, also je nachdem, wie viel auf dem Shop los ist, zum Beispiel eine Stunde lang keine Bestellung eingeht, dann würde ich sofort einen Alarm auslösen, weil da ist was kaputt.
Daniel Langemann: Das ist so Backup-mäßig,
Daniel Langemann: Also reicht auch oder ist kompensiert aber, dass ich keine schreibenden Tests gegen externe Systeme machen kann.
Daniel Langemann: Also, ja, sorry.
Kai Ole Hartwig: Ja, wir überspringen jetzt auch Punkte in der Pipeline, ehrlicherweise.
Daniel Langemann: Ja.
Kai Ole Hartwig: Du springst jetzt vom Testsystem aufs Produktivsystem.
Kai Ole Hartwig: Wobei, lass uns mal bei unserem Testsystem gerade bleiben und gleich aufs Produktivsystem springen, wenn wir dann doch was Kaputtes deployed haben.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Also was ich wichtig finde, ist halt, wenn, das deckt halt das tägliche Arbeiten ab in diesem Testszenario, ne?
Daniel Langemann: Mhm.
Kai Ole Hartwig: Wenn du, ähm, wenn du natürlich jetzt an Punkte kommst, die einmal vorkommen oder alle x Monate oder alle x Jahre vorkommen können, naja, API-Version und solche Dinge, ja, das passiert ja nicht unangekündigt über Nacht, ähm,
Kai Ole Hartwig: dann musst du halt anders testen, manuell nachtesten oder halt Vorwegstrategien haben.
Kai Ole Hartwig: Ich finde aber, das ist etwas, was man nicht in der Arbeit oder in der Pipeline für jeden Tag haben muss oder abdecken muss.
Daniel Langemann: Also genau, die Tests, also die Grundlage der Tests sind ja eigentlich nur, ich habe als Entwickler keinen Bock von Hand die Sachen durchzuklicken.
Kai Ole Hartwig: Ich finde so...
Daniel Langemann: Also normalerweise oder vor 30 Jahren war es ja gefühlt so, du hast geschrieben, hast durch den Browser geklickt, ja, kein Fehler, passt.
Kai Ole Hartwig: Nicht nur als Entwickler, auch als Gester und Product Owner.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und dann hat man halt immer die wichtigen Sachen vergessen und dann mit den Tests angefangen, die Sachen zu automatisieren und das dann auch viel besser, also jetzt End-to-End-Tests.
Daniel Langemann: Und das Ganze dadurch dann einfach viel besser zu machen, weil das wiederholbar ist und vorhersehbar ist und man kann nichts vergessen.
Daniel Langemann: Das ist ja eigentlich die Grundlage davon, ne?
Kai Ole Hartwig: Genau, und heute kannst du ja noch viel weitergehen.
Kai Ole Hartwig: Also wir hatten ja schon irgendwie gesagt, okay, diese langlebenden Secrets sind ziemlich unpassend heute.
Kai Ole Hartwig: Würde ich also nicht machen.
Kai Ole Hartwig: Selbst wenn man die rotiert, das löst halt einfach nicht das Problem.
Kai Ole Hartwig: Sowas wie OpenID Connect funktioniert halt auch ohne Probleme in der Pipeline mit Token.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Das sollte man sich immer überlegen, dass...
Kai Ole Hartwig: Im Prinzip eine Pipeline, wenn man den Credentials gibt, muss man die behandeln wie ein Produktivsystem.
Kai Ole Hartwig: In dem Moment, wo die Pipeline Zugriff auf Secrets bekommt, aus welchen Gründen auch immer,
Kai Ole Hartwig: musst du damit hantieren, als wäre das ein Produktivsystem.
Kai Ole Hartwig: Das heißt auch, du musst dann zum Beispiel in den Logs, die ja geschrieben werden und ausgegeben werden, dafür sorgen, dass da deine Secrets schon gar nicht mehr auftauchen.
Kai Ole Hartwig: Das ist halt sonst ein Megaproblem, wenn du jetzt sagst, ja, hier mein API-Key, den brauche ich aber, den schreibe ich mir jetzt irgendwo rein und dann steht er in jedem Log drin.
Kai Ole Hartwig: So.
Daniel Langemann: Also kleine Anekdote wieder zu dem Thema.
Daniel Langemann: Wenn du Entwickler bist oder wie es nicht sein sollte, du bist Entwickler, bist gerade was am Debuggen und brauchst Infos zu Umgebungsvariablen, machst natürlich einen Dump da drauf, weil du denkst, das ist eine ganz normale Config, du willst wissen, ob die Applikation gerade im Testmodus läuft und dieser Dump wird dann ausgegeben und da sind dann Credentials drin, weil auch die Container
Daniel Langemann: dann die Credentials in Umgebungsvariablen haben, ist das ganz schlecht.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, das ist nämlich auch genau der nächste Punkt.
Kai Ole Hartwig: Wenn du die Credentials so in den Container reinpackst, reinpackst, also reinpackst und da fixierst drin, dann sind sie halt letztendlich über die Registry immer abrufbar.
Kai Ole Hartwig: Dann kannst du halt sagen, na ja, komm, wurde ja netterweise mit reingeschrieben, so dann sind sie halt nicht mehr geheim.
Daniel Langemann: Hack mir ist doch verboten.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, jetzt kann man natürlich sagen, ja, das ist alles unser internes Netz, das ist alles sicher und alles toll bis zu dem Zeitpunkt, bis dann halt mal irgendjemand Zugriff drauf hatte, den man jetzt nicht mehr mag.
Kai Ole Hartwig: Oder, oder, oder.
Kai Ole Hartwig: Es gibt ja immer wieder den Fall, wo man sich überlegt, jetzt sollten wir doch nochmal die ganzen Secrets rotieren aus Gründen.
Kai Ole Hartwig: Das sind ja völlig unterschiedliche Gründe.
Kai Ole Hartwig: Aber wenn du halt die Secrets gar nicht in den Züge von einem bestimmten Personenkreis hast, dann kannst du halt die Notwendigkeit krass minimieren.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: Und das ist ja so, ich habe das auch häufig genug gesehen und wir haben das früher ja genauso gemacht in den Pipelines.
Kai Ole Hartwig: Das ist ja einfach der Erfahrungswert.
Kai Ole Hartwig: Das ist jetzt ja gar nicht so ein, ja, ihr dürft aber nicht.
Kai Ole Hartwig: Und ich mache das alles besser.
Kai Ole Hartwig: Ich habe nie solche Dinge gemacht, sondern das ist ja wirklich eine Entwicklung.
Kai Ole Hartwig: Das ist auch genauso, wie wir heute halt zum Beispiel noch hingehen und mit eigenen Policies prüfen, ob zum Beispiel gewisse Standards eingehalten sind, ja, ob bestimmte Benahmungen, ähm,
Kai Ole Hartwig: da sind in.end-Files, ja, auch wir nutzen an bestimmten Stellen.end-Files, die enthalten nur keine Credentials, ja, die enthalten halt so etwas wie, hey, die App läuft nicht in Debug, sondern sie ist auf produktiv gestellt, ja.
Daniel Langemann: Ganz normale Config, genau.
Kai Ole Hartwig: Genau, so.
Daniel Langemann: Also keine Secrets, sondern Konfiguration der Applikation, ja.
Kai Ole Hartwig: oder dass ein bestimmtes Feature jetzt eingeschaltet ist und solche Dinge.
Kai Ole Hartwig: Das schreiben wir ja auch in.env-Files und die prüfen wir oder wir prüfen auch unsere Compose-Templates.
Kai Ole Hartwig: Wir haben ja keine Compose-Dateien mehr in den Repositories drin, sondern wir haben ein Template und unser Makefile sorgt dafür, dass wir die richtigen Templates einbinden und nutzen anhand der Services, die wir brauchen, anhand der PHP-Pakete, die wir eingebunden haben.
Kai Ole Hartwig: Da prüfen wir halt auch mit Policies, ob das alles so stimmt, ja, ob zum Beispiel niemand irgendwie versucht, ein MySQL-Passwort so da reinzusneaken, sondern dass die immer über die Runtime kommen.
Daniel Langemann: Also nicht versehentlich mal Sachen mit committed werden oder so, ja.
Kai Ole Hartwig: Und
Daniel Langemann: Hm.
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Manchmal bist du ja in diesem Debuggen drin, änderst Sachen, um einfach mal voranzukommen.
Kai Ole Hartwig: Und umgehst bewusst die Mechanismen, die eigentlich da sind.
Kai Ole Hartwig: Und damit das aber nicht weiter wandert.
Kai Ole Hartwig: Also dann ist es schon committed, dann ist es schon im Repository gelandet.
Kai Ole Hartwig: Das ist doof.
Daniel Langemann: Den kann man noch wegschießen, ja.
Kai Ole Hartwig: Aber dann ist es immerhin nur auf einem Feature-Branch.
Kai Ole Hartwig: Den kann man wegschießen und dann sind es ja auch nur Dev-Credentials.
Kai Ole Hartwig: Dev-Credentials sind auch etwas, die kennen wir nicht, die generieren wir bei den Starts immer wieder neu.
Kai Ole Hartwig: Also so nach dem Motto, I don't care, welche, wie das Passwort für den Wall-Key ist oder für die Datenbank auch, also im
Kai Ole Hartwig: im lokalen System, ja, beim Starten wird die E gebaut und reingekopiert die Daten, leg halt einen User an mit dem Passwort, was jetzt gerade für diese Umgebung richtig ist.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Funktioniert übrigens hervorragend.
Kai Ole Hartwig: Ja, so, ist jetzt auch kein echtes Problem, so DevCredentials, aber dann ist es halt auch egal, ob sie da sind oder nicht da sind, wir brauchen sie nicht im Repo, sie werden automatisch generiert und
Kai Ole Hartwig: irgendwie ist es echt angenehm, ja, du musst nicht dran denken, irgendwas anlegen zu müssen, dass deine Entwicklungsumgebung läuft.
Kai Ole Hartwig: Wir waren aber in der Pipeline irgendwo und ich bin gedanklich falsch abgeboken.
Daniel Langemann: im entferntesten Sinn ist das ja noch Pipeline.
Daniel Langemann: Also aus dem Depp-System heraus
Kai Ole Hartwig: Ja, das ist der Schritt vor der Pipeline, genau.
Kai Ole Hartwig: Ah, genau, ich war bei den Policies.
Kai Ole Hartwig: Policies habe ich auch letztendlich im letzten Jahr erst so richtig angefangen zu benutzen.
Kai Ole Hartwig: Und mittlerweile liebe ich es, weil wir einfach diese Prüfschritte drin haben.
Kai Ole Hartwig: Entspricht das alles auch unserem Standard?
Kai Ole Hartwig: Haben wir nicht...
Daniel Langemann: Mit welchen Tools definierst du diese Policies denn?
Daniel Langemann: Also gibt es sowas wie, sagen wir mal, PHP-Stan oder CS-Fixer oder sowas, dass man sagen kann, ich konfiguriere mir solche Policies mit irgendeinem Tool zusammen und das lasse ich durch das Projekt durchlaufen oder?
Kai Ole Hartwig: Ja, also natürlich nicht mit CS-Fixer, sondern es gibt eigene losgelöste Tools.
Daniel Langemann: Nein, aber...
Kai Ole Hartwig: Lass mich die auch gerne kurz in unserem Setup nachschauen.
Kai Ole Hartwig: Ja, Namen sind ja Schall und Rauch für mich.
Kai Ole Hartwig: Und du fragst mich direkt nach Tool-Namen, Dani.
Kai Ole Hartwig: Das ist hervorragend.
Kai Ole Hartwig: Warte mal, ich muss mal mein geliebtes PHP-Storm an dieser Stelle kurz aufmachen.
Kai Ole Hartwig: meine große Schwäche sind ja Namen.
Daniel Langemann: Gerade weil man es niederschreibt, muss man sich das eh nicht merken.
Kai Ole Hartwig: Ja, genau, das ist so dieses reingeschrieben, das steht ja auch in unseren Tools.
Daniel Langemann: Ich sage immer, mein Kontext.
Kai Ole Hartwig: Und die Dateiendung ist Rego.
Daniel Langemann: Riko.
Kai Ole Hartwig: Das ist gut.
Kai Ole Hartwig: Warte mal.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, also können wir eine andere Folge mal drüber machen, wo wir wirklich spezifischer drauf eingehen, weil das würde mich echt interessieren, wie man das definiert und was man da genau machen kann.
Kai Ole Hartwig: Ja, vielleicht
Daniel Langemann: Aber generell finde ich es gut zu sagen, es gibt Sachen, die zum Beispiel nach Secrets oder nach Credentials suchen, nach Variablen, die einfach darauf hindeuten, dass Secrets im Code sind, denke ich mal.
Kai Ole Hartwig: Genau, nach klassischen Patterns, so was, wenn irgendwo bestimmte Worte dran stehen, dann finden wir es doof.
Daniel Langemann: Ja, genau.
Daniel Langemann: Ja.
Kai Ole Hartwig: So was wie API oder Key.
Kai Ole Hartwig: So, das ist so das erste Ding, was dann gefleckt wird, wenn du das in der.env-Datei oder in einer.env-Datei findest, dann mach mal erst mal hier dicht und sag, nee, sorry.
Kai Ole Hartwig: so.
Kai Ole Hartwig: Tool.
Kai Ole Hartwig: Wäre ja was.
Daniel Langemann: Ich finde eine extra Folge dafür gut.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: So, was uns aber auch dazu führt...
Kai Ole Hartwig: ich muss jetzt aufpassen, dass ich persönlich gedanklich nicht so sehr springe heute, dass man heute halt auch hingehen kann, wunderbarerweise,
Kai Ole Hartwig: und CI, CD-Components, wie sie GitLab hat, jetzt bin ich natürlich wieder sehr tool-lastig und sage, okay, in GitLab ist das so, aber das Prinzip funktioniert, glaube ich, überall, dass man diese einzelnen Jobs, die man hat, mit Tests versieht und schaut, dass die auch getestet sind und eine eigene Release-Pipeline haben.
Kai Ole Hartwig: Also unsere Jobs bauen sich zum Beispiel, Pipelines bauen sich aus festen Komponenten,
Kai Ole Hartwig: auf und bevor wir eine neue Version releasen, davon durchlaufen die auch Tests und werden dann automatisch released.
Daniel Langemann: Also die Pipeline selber.
Kai Ole Hartwig: Also, ja, die Pipelines selber.
Kai Ole Hartwig: Auf die dann wieder die gleichen Sicherheitsregeln im Übrigen gelten.
Kai Ole Hartwig: Ja, auch da schauen wir, gibt es Secrets da drin?
Kai Ole Hartwig: Verlieren wir irgendwas?
Kai Ole Hartwig: Ist da was Auffälligges?
Kai Ole Hartwig: Und die Hauptfrage, funktionieren die?
Kai Ole Hartwig: Stell dir vor, wir pushen jetzt eine neue Version für das Bauen von Images.
Kai Ole Hartwig: Und uns geht dabei die S-Bomb-Generation verloren.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Das wäre halt für uns irgendwie dumm.
Kai Ole Hartwig: oder ungünstig, sagen wir mal, weil dann natürlich weitere Schritte irgendwie nicht funktionieren und durchlaufen.
Kai Ole Hartwig: Oder die Signierung von Images geht kaputt oder von Paketen.
Kai Ole Hartwig: Das können wir halt dadurch, dass wir vorher die Pipeline prüfen, vor dem Release, also den Job prüfen mit Tests und dann erst releasen, können wir das halt sicherstellen, dass die einzelnen Jobs immer
Kai Ole Hartwig: funktional bleiben, immer so funktionell wie wir es definiert haben.
Kai Ole Hartwig: Und bei uns ist es halt auch noch so, sobald wir eine neue Version von so einer CI-CD-Component erstellt haben, geht halt Renovate hin und updatet alle Abhängigkeiten in den anderen Repositories.
Kai Ole Hartwig: Renovate ist ein Tool, womit du Dependency-Updates automatisieren kannst.
Daniel Langemann: Oh.
Kai Ole Hartwig: Sprich, er prüft regelmäßig
Kai Ole Hartwig: nicht nur interne, sondern auch externe Abhängigkeiten, gibt es hier eine neue Version.
Kai Ole Hartwig: Und in unserem Fall ist es so konfiguriert in bestimmten Grenzen natürlich.
Kai Ole Hartwig: Wenn es eine neue Version gibt, geh hin, CD macht zum Beispiel das Composer Update.
Kai Ole Hartwig: machen Merch-Requests dafür auf, also ein neuer Feature-Brand oder eine neue Branche, Merch-Requests aufmachen, dann läuft die Pipeline durch und wenn die Pipeline erfolgreich ist, dann mercht der auch selbstständig und lässt das zum Teil bis aufs Produktivsystem durchbauen.
Daniel Langemann: Hm, geil.
Kai Ole Hartwig: So, bedeutet aber auch an der Stelle wieder, wir haben automatische Tests, die halt vollautomatisch durchlaufen können.
Kai Ole Hartwig: Und ich habe ja eben schon sowas anklingen lassen wie S-Bomb und Signierung.
Kai Ole Hartwig: Das sind auch aus meiner Sicht heute zwei enorm wichtige Baustellen in so einer Pipeline drin und in dem Ganzen, was wir eigentlich mit der Pipeline auch an Sicherheit erreichen wollen.
Kai Ole Hartwig: Wir möchten am Tagesende
Kai Ole Hartwig: dass das Ergebnis, was wir rausbringen, dem entspricht, was wir getestet haben und wir aber auch jederzeit wissen, was es enthalten, wurde das tatsächlich von uns rausgegeben und ist das auch heute noch sicher.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Also, stellen wir mal vor, uns fällt Renovate aus und das macht keine automatischen Updates.
Kai Ole Hartwig: Kann ja passieren.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: Oder irgendwo der Prozess hängt oder whatever.
Kai Ole Hartwig: Die S-Bomb, die generiert werden kann, das ist ja so eine lange JSON-Datei, die kann ja kein Mensch lesen.
Daniel Langemann: Was ist das genau?
Kai Ole Hartwig: Die enthält aber und wurde hoffentlich zur Build-Zeit gebaut.
Kai Ole Hartwig: Also nicht erst irgendwann später mal noch nachgezogen oder so, sondern in dem Moment, wo man alles zusammenbaut, erstellt man diese S-Bomb.
Kai Ole Hartwig: und enthält alle eingesetzten Pakete, Software, whatever, die halt in so einem Image und in deiner Applikation enthalten sind.
Kai Ole Hartwig: Und das mit der jeweilig verwendeten Version.
Kai Ole Hartwig: Sprich, wir wissen eigentlich zu dem Zeitpunkt dann, welche Pakete sind enthalten und welche sind nicht mehr sicher.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und dieses...
Kai Ole Hartwig: Das ist ja in dem Moment, wo ich das baue, nur eine Momentaufnahme.
Kai Ole Hartwig: Was ich dann machen muss mit dieser Information, ist aber auch, einen Pipeline-Job zu haben oder ein Tool oder whatever.
Kai Ole Hartwig: Irgendein Prozess, der dafür sorgt, dass dieses Bild-Artefakt, was es ja ist, die S-Bomb,
Kai Ole Hartwig: mit der Version verbunden ist und dann immer wieder periodisch geprüft wird, sind für die eingesetzten Versionen neue Sicherheitslücken bekannt geworden.
Kai Ole Hartwig: Dass ich zu jedem Zeitpunkt weiß, welche Lücken habe ich denn und muss ich jetzt handeln?
Daniel Langemann: Sind neue dazugekommen, ja.
Kai Ole Hartwig: Ist da etwas Kritisches drin, wo ich jetzt sofort was machen muss?
Kai Ole Hartwig: Also ich meine, in unserem Prozess würde hoffentlich Renovate, wie gesagt, schon dafür gesorgt haben, dass die neue Version eingespielt ist und alles cool ist.
Kai Ole Hartwig: Aber wie gesagt, es kann halt auch immer sein, dass Renovate so eine neue Version nicht bekommt, dass dann Breaking Change ist, dass irgendwas kaputt gegangen ist, wir etwas umkonfigurieren müssen und die Pipeline nicht automatisch durchläuft.
Kai Ole Hartwig: Also sprich, du brauchst eine Form von Monitoring und Alerting auf die eingesetzten Pakete, damit du mitbekommst, oh, ich muss jetzt aber handeln.
Kai Ole Hartwig: Und das macht dann nicht deine Pipeline sicherer an der Stelle, sondern deine Applikation, aber gehört ja auch irgendwie in diesen Pipeline-Prozess rein.
Kai Ole Hartwig: Jetzt waren wir schon auf dem Testsystem, wir haben irgendwie adressiert, okay, wir wissen, was ist da drin, was wir dann noch machen, was das Ergebnis sicherer macht, gar nicht die Pipeline, ist mit Cosign hingehen und
Kai Ole Hartwig: uns.
Daniel Langemann: Vielen Dank.
Kai Ole Hartwig: Überprüfbar und im Prinzip sichtbar, was auch bedeutet, wenn wir uns ein Image ziehen,
Kai Ole Hartwig: dann prüfen wir auch die Signatur.
Kai Ole Hartwig: Wenn die Signatur ungültig ist, dann sehen wir die nicht mehr.
Daniel Langemann: Ja, also das mit den Images und den Signaturen kenne ich.
Kai Ole Hartwig: Hm?
Daniel Langemann: Also ich kenne zum Beispiel den Ansatz ein bisschen anders, dass der Gedanke ist, man baut die Applikation fertig in einem Container.
Daniel Langemann: Also es bezieht sich auch wirklich nur auf Docker, also entweder ECS oder hier Kubernetes oder so.
Kai Ole Hartwig: Ja, ist ja...
Daniel Langemann: baust deine Applikation im Container fertig, signierst das Ganze und das ist sozusagen dein Bildartefakt und das Ding kannst du dann durchdeployen und hast sozusagen die Unveränderlichkeit.
Daniel Langemann: Also ich glaube, das ist ähnlich wie mit dem S-Bomb so ein bisschen.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Also diese Unveränderlichkeit zumindest festgestellt, dass in Prod die gleiche Konstellation von Abhängigkeiten genutzt wird wie im Testsystem.
Daniel Langemann: Aber was
Kai Ole Hartwig: Also die S-Bomb beschreibt ja, was du drin hast und das Signieren sorgt ja nur dafür, was heißt sorgt nur dafür, sagt halt, okay,
Kai Ole Hartwig: hier, die haben es rausgebracht und wenn du halt statt einer Versionsnummer zumindest bei Container-Images hingehst und die Digits nimmst oder wie auch immer man das ausspricht, also den Char-Wert, dann sorgst du ja dafür, dass du wirklich die Version nimmst, die du haben möchtest.
Daniel Langemann: Ja.
Kai Ole Hartwig: Das ist zum Beispiel auch etwas, was wir machen.
Kai Ole Hartwig: Wir nutzen diesen
Kai Ole Hartwig: unfassbar langen String, den Hashwert, zum Identifizieren, welche Version wollen wir dann ausspielen.
Kai Ole Hartwig: Oder welche Version wird da genutzt?
Kai Ole Hartwig: Da steht zwar vor, dann unsere semantische Versionssummer, aber letztendlich beziehen wir uns immer darauf, welcher Hash es ist.
Daniel Langemann: Ja, macht es dann auch.
Daniel Langemann: Also der Hash ist dann der Comet-Hash oder aus dem signierten Container?
Daniel Langemann: Sorry.
Kai Ole Hartwig: Boah, du stellst hier eine Frage.
Daniel Langemann: Also ich frage deswegen, weil, also ich nutze gerne den Comet-Hash, weil in der Pipeline dann recht einfach auch Rollbacks machbar sind, dass du sagen kannst, guck mal, ich triggere, also produktiv hat nicht funktioniert, ist irgendwas gefailt, ich kann die Pipeline davor nochmal triggern und dann wird der Container
Kai Ole Hartwig: Das ist...
Daniel Langemann: Also wenn der Container Hash gleich dem Comet Hash ist, dann hast du ja eine recht einfache Versionierung drin und kannst sagen, das ist das Artefakt.
Kai Ole Hartwig: Du nimmst quasi den Commit-Hash als Versionsnummer.
Kai Ole Hartwig: Ja, wir nehmen da semantische Versionsnummern.
Kai Ole Hartwig: Also, sprich...
Daniel Langemann: Sieht schöner aus, aber dann musst du da hin und her rechnen und dafür war ich zu faul.
Kai Ole Hartwig: Ja, wir setzen aber halt an jedes Paket, das wir bauen, also auch an die Gesamt-CMS-Applikationen, also an das Gesamt-CMS-Paket mit allen Extensions und so weiter, setzen wir die semantische Versionsnummer.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Da legen wir die fest und übergeben die an die Container-Pipeline, die den Container baut.
Kai Ole Hartwig: Und der Commit-Hash ist auch so ein Ding.
Kai Ole Hartwig: Also im Prinzip ist es ein Git-Tag, den wir da weitergeben, der die Versionsnummer macht, aber die Digits, also dieser Hash, der das in Absolut für Docker oder oder Kubernetes oder, oder, oder identifiziert, das ist nochmal ein Ding, was halt bei dem Bild von dem Image entsteht.
Daniel Langemann: sehr mathematisch gleich.
Kai Ole Hartwig: der leitet sich jetzt nicht irgendwie ab aus der Versionsnummer oder aus irgendetwas, was du selber dranhängst, sondern das ist nochmal ein anderer Heft, der, ich weiß leider nicht, wie der berechnet wird, aber der halt ganz eindeutig jetzt dieses eine Image identifiziert und der auch nicht veränderlich ist.
Kai Ole Hartwig: Weil du könntest ja zum Beispiel einfach ein Container-Image löschen,
Kai Ole Hartwig: und den gleichen Tag nochmal vergeben.
Kai Ole Hartwig: Also egal, ob das ein Commit ist oder eine semantische Versionsnummer, du könntest halt sagen, okay, bau mir halt Latest nochmal neu.
Kai Ole Hartwig: Und Latest ist ja so ein Ding, was zum Beispiel ja total häufig ver... Ja, genau.
Daniel Langemann: Niemand benutzt Latest.
Kai Ole Hartwig: Aber was ja einfach gar keinen Bezug zur Realität hat, das ändert sich ja, was Latest ist.
Daniel Langemann: Ja, also du kannst in dem Repository einstellen, dass Tags, also in dem Container Repository, dass Tags nicht wiederverwendbar sind.
Kai Ole Hartwig: Ja, musst du halt machen.
Daniel Langemann: Also das habe ich jetzt natürlich nicht gesagt, aber davon gehe ich aus, weil ansonsten hast du ganz viele Probleme, wenn Tags nicht wieder, wenn Tags wiederverwendet werden oder wiederverwendbar sind.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also hier die üblichen Pod, Dev und Staging Tags, wo die Container immer neu gepusht werden.
Daniel Langemann: Aber da hast du andere Probleme dann.
Daniel Langemann: Richtig.
Kai Ole Hartwig: Habe ich nicht, weil haben wir ja gesetzt.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Aber sowas wie Latest ist halt so ein Standardding.
Kai Ole Hartwig: Jeder schreibt irgendwie Latest und jeder schreibt irgendwie Def.
Kai Ole Hartwig: Und da entstehen natürlich, wenn du das so machst, hast du natürlich irgendwann Probleme.
Kai Ole Hartwig: Es ist auch total toll, immer Latest zu ziehen.
Kai Ole Hartwig: Das gibt Sicherheit, dass man weiß, was drin ist.
Daniel Langemann: Ja, es ist natürlich einfacher, ein Skript zu schreiben, also in meinem Kontext jetzt mit AWS oder so, ist es einfacher ein Skript zu schreiben, was einfach sagt, ne, baue oder deploy diesen Task nochmal neu und die Version soll latest sein.
Daniel Langemann: Easy festgeschrieben, weil ansonsten musst du ja bei jedem Deployment rausfinden, was die Version ist, die deployed wurde und auch den AWS-Task anpassen.
Daniel Langemann: Also du musst so ein bisschen mehr machen und ich kann nicht schon verstehen, dass dann es einfacher ist oder dass man dann geneigt ist zu sagen, ich möchte prod, dev oder stage deployen.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Kann man so machen.
Daniel Langemann: Das ist ein fester Wert und den muss ich nicht irgendwo herbekommen.
Daniel Langemann: Hm.
Kai Ole Hartwig: kommt halt darauf an, was man an einem weiteren Setup haben möchte.
Kai Ole Hartwig: Ich sage jetzt mal, das ist ja auch so ein gewisser Reifegrad, der sich entwickelt.
Kai Ole Hartwig: Niemand startet damit und sagt jetzt, ich baue jetzt die perfekte Pipeline oder den perfekten Cluster, sondern das ist ja ein Aufbauen und eine Evolution und es verändert sich ja auch mit den Dingen, die
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: man erfüllen will oder erfüllen muss oder der Erfahrung auch haben.
Kai Ole Hartwig: Wenn dir fünfmal oder vielleicht auch zwei-, dreimal nur das System kaputt gegangen ist, dann schreibst du ja hoffentlich irgendwann einen Test dafür, dass das nicht mehr passiert.
Kai Ole Hartwig: So.
Kai Ole Hartwig: Und genauso funktioniert das ja mit Pipelines und diesen ganzen Prozessen.
Kai Ole Hartwig: Es ist ja nicht so, dass auch die Pipelines und die Steps, die wir jetzt gerade hier machen,
Kai Ole Hartwig: dass das über Nacht entstanden ist.
Kai Ole Hartwig: Also ich habe irgendwann mit CI-CD angefangen, als Jenkins noch Hudson hieß.
Daniel Langemann: Oh ja, mhm.
Kai Ole Hartwig: So, und irgendwann saß ich dann auch mal in einer Runde, wo jemand seine Probleme mit der CI-CD-Pipeline berichtet hat und erzählt hat, naja, wir spielen das dann auf den Testserver aus und dann machen wir Composer Update.
Kai Ole Hartwig: Und dann spielen wir das auf den Produktiv-Server auf und da machen wir Composer Update.
Kai Ole Hartwig: Und dann halt so dieses Problem beschrieben hat, was auch ganz logisch ist, wenn man halt weiß, wie das funktioniert, aber ganz logisch war an der Stelle.
Kai Ole Hartwig: dass dann halt die Versionen und gar nicht stimmt und da geht immer so viel kaputt und irgendwie ist dieses automatische Deployment ja überhaupt gar nicht sinnvoll und diese Pipelines, das hilft ja alles nichts.
Kai Ole Hartwig: Früher war alles besser mit FTP so ungefähr, aber das ist halt so ein, man muss sich halt daran gewöhnen, im ersten Schritt dieser Pipeline wird meinetwegen das Composer Update gemacht,
Daniel Langemann: SFTP.
Kai Ole Hartwig: wenn man das automatisch macht, weil man mit Paketen arbeitet, die dann das triggern.
Kai Ole Hartwig: Und danach ist das aber festgelegt und wenn man jetzt nicht diese Bildartefakte mitschleppt, dann macht man immer ein Composer.
Kai Ole Hartwig: Ja, eigentlich ist halt
Daniel Langemann: Ja.
Kai Ole Hartwig: macht man in einer Pipeline, außer man hat so eine automatisierte Update-Pipeline-Geschichte da, idealerweise mit Renovate oder einem anderen Tool, das es macht, Depender-Bot oder so, hast du halt ja nie das Bedürfnis oder solltest du nie das Bedürfnis haben,
Kai Ole Hartwig: einfach Updates zu machen, ja, zu sagen, hier Composer Update und vor allem nicht, wenn du auf dem Server direkt drauf deployst, gar nicht mit Containern arbeitest und da sagst, das ist ein anderer Pipeline-Cheap irgendwie, ne, da brauchst du dir ja den Image-Bild, aber dann, dann
Daniel Langemann: Hmm.
Kai Ole Hartwig: hast du idealerweise ja auch in der Pipeline das PHP-Artefakt quasi zusammengebaut, das du dann rüberkopierst mit AirSync, ohne Git, ohne Tests, ohne, hast du nicht gesehen, ja, dass man auch diese Dinge rauslässt, Testfälle zum Beispiel gehören gar nicht auf ein Produktivsystem am Tagesende.
Kai Ole Hartwig: Also diese PHP-Unit-Testsachen, die ließen bei uns gar nicht mit in das Produktive oder in das Image dann rein.
Kai Ole Hartwig: Selbst in das Test-Image sind sie nicht drin, nachher reingebaut.
Daniel Langemann: Sollten sie auch nicht.
Kai Ole Hartwig: Das sind alles Sachen, die vorher ausgeführt werden und dann wird gefiltert.
Daniel Langemann: Ich meine, das wird sich halt zurückgehen.
Daniel Langemann: Hm.
Kai Ole Hartwig: Und genauso, wenn man halt auf Bare Metal oder V-House oder so rübergeht, ist es ja nicht so, dass auch Composer da leben sollte.
Kai Ole Hartwig: Also Composer sollte da auch als Executive gar nicht existieren.
Kai Ole Hartwig: Aus meiner Sicht, ja, du möchtest da gar kein Composer-Install machen.
Kai Ole Hartwig: Du möchtest eigentlich dein festes Set an PHP-Dateien nehmen und
Kai Ole Hartwig: dort rüberbringen und dann hoffentlich bitte nicht den SSH-Key in der Variable im GitLab haben als protected, sondern sondern bitte über OIDC oder meinetwegen über ein Secret, das man aus einem Vault oder so gezogen hat, sich anmelden kann.
Daniel Langemann: Ja.
Kai Ole Hartwig: weil wenn du auch, also egal wo, in allen, in der Statistik, OWAPS Top 10 ist es so, dass in den nicht-menschlichen Interaktionen langlebende Secrets auf Platz 3 im Moment platziert wurde in den Top 10.
Kai Ole Hartwig: Und ich glaube, dem sollte man
Kai Ole Hartwig: bisschen mehr Aufmerksamkeit schenken und sagen, okay, lasst uns schauen, dass wir die Secrets möglichst rausbekommen und nur mit kurzlebigen Dingen arbeiten zum Identifizieren und auch so Sachen nutzen wie MTLS etc.,
Daniel Langemann: Mhm.
Kai Ole Hartwig: dass wir unsere Prozesse sauber haben, ohne Secrets, ohne Credentials auskommen.
Kai Ole Hartwig: Und dann quasi wie hier unser Podcast unterwegs ist mit Secrets not included, dass man das so ein bisschen zum Motto der Pipelines und Container und Bildartefakte macht, dass die Geheimnisse tatsächlich einfach nur in der Runtime existieren.
Daniel Langemann: Was ich als Fazit aber noch ganz gut fand, das hast du gerade eben kurz angeschnitten, niemand kommt in ein Projekt und baut eine fertige Pipeline bis zum Ende und in alle Richtungen ausgeprägt, sondern das ist
Daniel Langemann: Immer nach Bedarf, je nach Teamgröße, gesetzliche Vorschriften, was auch immer, gibt es ganz viele unterschiedliche Anforderungen.
Daniel Langemann: Und dieses, ich würde jetzt auch von vornher nicht hingehen und direkt alles einbauen, sondern erst mal bauen, automatisieren, dann sagen, was sind die nächsten großen Schmerzen.
Daniel Langemann: Und die können je nach Projekt unterschiedlich sein.
Daniel Langemann: Also es gibt nicht one size fits all.
Daniel Langemann: Und das ist die Pipeline, die macht alles richtig und ihr alle anderen macht alles falsch.
Daniel Langemann: Das gibt es nicht.
Kai Ole Hartwig: Also das Einzige, wo ich dir widerspreche, S-Bone.
Kai Ole Hartwig: Das musst du aus Compliance-Gründen halt haben, genauso wie das Monitoring darauf.
Kai Ole Hartwig: Das sind halt gesetzliche Anforderungen und ansonsten
Kai Ole Hartwig: Pain-Driven Development.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Oder man hat halt, man sagt halt, okay, wir nehmen ein Set, das macht schon sehr, sehr viel von diesen Dingen, die wir haben wollen und das funktioniert und zieht sich öffentlich aus die ICD-Components für die Sachen rein und baut sich halt das quasi wie mit Lego zusammen.
Kai Ole Hartwig: Ja, mit Klemmbaustein, man darf ja Lego gar nicht sagen.
Kai Ole Hartwig: mit Klemmbausteinen zusammen und ist dann damit schneller.
Kai Ole Hartwig: Man muss das Rad nicht neu erfinden, auch bei Pipelines heute nicht mehr.
Kai Ole Hartwig: Ja, Ja, so.
Daniel Langemann: Das ja stimmt.
Kai Ole Hartwig: Ich glaube, das ist ein gutes Fazit.
Kai Ole Hartwig: Kleinstarten, groß werden, wiederverwenden, S-Bomb erfüllen, weil man das erfüllen muss und gut ist.
Kai Ole Hartwig: Der Rest ist geschenkt.
Kai Ole Hartwig: Und Und vielleicht noch zum Schluss, also man kann ja auch immer erfahrene Leute Fragen anschreiben.
Kai Ole Hartwig: Und es gibt, glaube ich, wenig Menschen, die jetzt sagen, wir finden da keine Lösung, wie man euch da weiterbringt.
Daniel Langemann: Fragen kosten nichts.
Daniel Langemann: Zumindest als Beratung.
Daniel Langemann: Dann ciao.
Kai Ole Hartwig: Ja, die erste Frage kostet nichts ungefähr.
Kai Ole Hartwig: Wunderbar.
Kai Ole Hartwig: Dann, glaube ich, sind wir am Ende unserer wunderbaren Folge diese Woche und sehen uns nächste Woche wieder.
Kai Ole Hartwig: Bis dahin.
Kai Ole Hartwig: Macht's gut.
Kai Ole Hartwig: Tschö.
