​Wir kennen es alle. Solange du brav an deinem Schreibtisch sitzt, Kaffee trinkst und die Monitore im Blick hast, passiert absolut gar nichts. Die Cluster schnurren wie Kätzchen. Aber wehe, du packst deine Sachen, sitzt im Zug oder bist gerade mit dem Camper auf dem Weg in den Urlaub – genau dann fliegen dir plötzlich alle Alerts um die Ohren, die du jemals eingerichtet hast.
​Das System brennt.
​Jetzt beginnt das klassische Drama: Du klappst auf dem Beifahrersitz das Notebook auf, aber die IT-Abteilung deines Vertrauens (oder das restriktive Hotel-WLAN) blockiert natürlich Port 22 oder worauf auch immer du dein SSH gelegt hast.
​Dein Git-Server ist zwar über HTTPS erreichbar, aber du kriegst die korrigierten Manifeste nicht ins Kubernetes-Cluster geschossen, weil die API nur von intern erreichbar ist. Ach ja, und das VPN-Zertifikat auf deinem Laptop ist praktischerweise auch seit drei Tagen abgelaufen.


​Game Over.

​In solchen Momenten merkt man erst, wie anfällig diese klassischen „Ich mache alles auf meinem lokalen Rechner in der Shell“-Workflows eigentlich sind. Und um mal ganz ehrlich zu sein: Warum sollte man sich diese Arbeit im Alltag überhaupt antun?
​In meinen Augen ist dieses krampfhafte Festhalten am Terminal-Zwang oft reines Gatekeeping von Leuten, die sich wichtig fühlen wollen. Ich bin froh um alles, was ich nicht tun muss, weil ich einmal richtig Effort in die "Automatisierung" gesteckt habe.
​Konstruktive Faulheit nennt sich das. Und die bessere Web-UI gewinnt unterwegs einfach jedes einzelne Mal gegen die Shell, weil ich per HTTPS aus nahezu jedem Netzwerk und im Zweifel sogar vom Smartphone aus handlungsfähig bleibe.

​Die Terminalarme Zone: Irgendwie Dev und Ops im Browser, irgendeinem modernen Browser

Wenn man die Infrastruktur konsequent zu Ende denkt, wird das lokale Terminal vom primären Werkzeug zum reinen Notfall-Fallback. Im Grunde mache ich im Office nur meine IDE auf, die natürlich sauber auf meine Bedürfnisse angepasst ist.

Ja, auf der Shell kann ich viele Dinge auch sehr bequem machen und auch reproduzierbar Skripten. Das ist richtig und wichtig, aber wenn ich im Urlaub bin möchte ich Quality Time mit der Familie haben und nicht den Servern.

Mit einer Mannigfaltigkeit an Extensions und KI Agenten und LLM Skills. Oder halt in der Kantine am Smartphone in der Web IDE des Versionsführungssystems meines Vertrauens mit Syntax-Highlighting, Fix eintippen, Commit direkt im Browser -> Done, zwischen dem Mittagessen und Nachtisch während ich mit den Kollegen plaudere. Kein lokales Auschecken, kein git pull-Frust auf einer wackligen LTE-Verbindung.


​Für den Betrieb gilt genau dasselbe. Warum sollte ich mich mit kubectl logs durch Namespaces wühlen? Das ArgoCD Dashboard zeigt mir den gesamten Zustand des Clusters visuell an. Ein Klick auf "Sync", ein Klick auf den betroffenen Pod, und ich sehe die Container-Logs formatiert und durchsuchbar im Browser. Selbst wenn ein kompletter Node die Grätsche macht, brauche ich kein lokales IT-Setup hochzufahren.

Dann tut es auch die Webshell im Cloud-Dashboard des Hosters oder Hypervisors. Das Problem ist gelöst, bevor die Shell auf meinem Laptop überhaupt gestartet ist.

Der Elefant im Raum: Cyber Sicherheit, ja wir sind hier in good ol' Germany.

Wenn ich von diesem Setup erzähle, sagen viele sofort: „Geile Automatisierung!“ Aber ehrlich gesagt ist es das am Ende gar nicht mal. Ich sage: Es ist das moderne Bare Minimum.

Egal wie du es drehst und wendest, das Internet ist kein Neuland mehr. Als Millennial oder Generation Y habe ich meine ersten Gehversuche im Internet mit AOL gemacht und irgendwann dann herausgefunden, dass mein Modem nicht "let me sing you the Song of my people" machen muss wenn ich Netscape öffnen will um wirklich schrecklichen, blinken Seiten beim laden zusehen wollte. Klar musste meine Mutter Mal Telefonpause machen weil Dinge gerade geladen haben. Und natürlich hat sie das das gekonnt ignoriert.
Aber das ist ehrlicherweise ca. 30 Jahre her und wir alle, die da nie rausgekommen sind und sich dann noch gedacht haben - "Geil, ich mach was mit Computern" - dürfen halt nicht in der Vergangenheit stecken und müssen einsehen: Der Browser ist mehr als nur Input für mich, er ist auch Input für die Infrastruktur.

Und hier fing es bei mir dann an. Ich kann alles im Browser machen, programmieren, deployen. Aber Passwörter und andere dinge die wichtig wären? In ein Repo packen? Auf gar keinen Fall. Das ist ja wie den Schlüssel unter die Matte legen und dann noch in der Zeitung sagen das man im Urlaub ist und sagen das man niemals nie unter der Matte nachsehen sollte.

Und ja, jetzt müssen wir über den Elefanten im Raum sprechen: Security.
​In der IT-Security gibt es oft diesen theoretischen Absolutismus: Alles komplett abschotten, VPN-Zwang, Zero-Trust bis zur totalen Handlungsunfähigkeit. Klar, das minimiert die Angriffsfläche. Aber machen wir uns nichts vor: Der Kosten-Nutzen-Faktor ist da irgendwann einfach drüber. SSH offen im Netz stehenzulassen, ist grob fahrlässig. Aber jeglichen Zugang zu wichtigen Systemen von außerhalb für den Notfall komplett abzuriegeln, ist eben auch eine Gefahr.

Wenn die Hütte brennt, zählt jede Minute, und im Unternehmen kostet jede dieser Minuten richtig Geld.
​Versteh mich nicht falsch: Ein offenes Web-Interface ist kein Freifahrtschein. Nur weil wir HTTPS davorhängen und ein IAM mit MFA vorschalten, ist das System nicht unknackbar. CVEs sind real, Zero-Days passieren jeden Tag, und wer das Protokoll kennt, weiß, wie simpel sich manche 2FA-Methoden aushebeln lassen. Und gerade im KI Zeitalter ist das umso wichtiger zu wissen - Die Wahrheit ist: Sicher ist ein System nur, wenn es gar nicht erst da ist.
​Es geht hier also nicht um blinde Naivität, sondern um eine bewusste Risikoabwägung. Ich schotte meine kritische Infrastruktur (wie die Kubernetes-API oder SSH) rigoros ab.

Aber für die Steuerungsebene, wie den Secret-Store, wähle ich den Weg der kontrollierten Zugänglichkeit. Ich nehme das restliche, bewusste Risiko eines gehärteten Web-Interfaces in Kauf, weil der Nutzen im Ernstfall (die sofortige Handlungsfähigkeit von überall aus) den potenziellen Schaden überwiegt.

Der ESO-Standard: Das geht doch so am besten... Oder?

Wer im Kubernetes-Umfeld nach einer Lösung sucht, um Secrets deklarativ in den Cluster zu bekommen, landet unweigerlich beim Platzhirsch: dem External Secrets Operator (ESO). Ich habe mich natürlich auch tief in HashiCorp Vault, den ESO und die üblichen Verdächtigen eingelesen. Und ja, generell mag ich es, Dinge selber zu hosten. Aber beim Secret-Management habe ich mich ganz bewusst dagegen entschieden, bzw bewusst für eine Lösung entschieden mit eigenem CR.


Versteh mich nicht falsch, der ESO ist ein feines Stück Software. Er holt Secrets von außen ab und schiebt sie als natives Secret in den Namespace. Aber der ESO ist nur der Consumer. Die Quelle dahinter musst du selbst stellen und betreiben. Vault, ein Cloud-Provider, oder eben auch Infisical.
Wer hier zum populären Default greift, holt sich mit Vault genau das komplexe Stück ins Haus, das ich nicht betreiben will. Mir war das zu viel Maschine für zu wenig Nutzen.
Ich gehe stattdessen den direkten Weg über Infisical und dessen eigenen Operator. Ja, ich könnte Infisical auch über den ESO anbinden. Wollte ich aber nicht. Wozu der generische Allzweck-Adapter, wenn ich nur ein Backend brauche und der Hersteller den passenden Operator gleich selbst liefert?
Infisical lässt mir dabei die Wahl: selbst hosten oder Cloud. Ehrlicherweise bin ich in der Cloud, um eine physische Trennung zu haben... (Physisch in riesigen Anführungszeichen).

Im normalen Alltag läuft das Setup vollkommen geräuschlos über Custom Resources (CR) pro Namespace ab. Ich definiere im Cluster nur noch deklarativ die Brücke: „Lieber Namespace, hier ist deine Infisical-CR. Schau bitte dort nach, was du für deine Apps brauchst.“
​Sobald ich im Browser ein Secret ändere oder neu würfele, triggert das den deklarativen Fluss im Hintergrund: Der Operator im Cluster erkennt die Änderung, holt sich den neuen Soll-Zustand ab und spiegelt das Secret als natives Kubernetes-Secret in den Namespace.

Und weil moderne Pipelines auch außerhalb des Clusters leben, synchronisiert Infisical die exakt gleichen Secrets bei Bedarf parallel direkt in meine GitHub-Repository-Secrets. Keine IDE, kein Terminal, kein YAML-Gefrickel.


​Der eigentliche Clou an diesem Ansatz ist aber, dass die Secrets im Cluster am Ende nur gelesen werden können. Das Ganze ist ein reiner Pull-Mechanismus, der mir im Ernstfall den Arsch rettet und den potenziellen Schaden (den sogenannten Blast Radius) massiv eindämmt.
​Spielen wir den Super-GAU mal durch: Ein Angreifer findet eine Lücke, bricht in einen deiner Container ein und kapert das System. Ja, das ist verdammt uncool, und natürlich gehört da noch eine ordentliche Portion Container-Security dazu, das gehört genauer in einen eigenen Artikel aber hier Mal grob:

Der Angreifer sieht jetzt die aktuellen Secrets dieses einen Namespaces. Aber das war es dann auch. Es ist kein Genickbruch für die gesamte Infrastruktur.
​Warum? Weil ich im Ernstfall einfach mein Smartphone zücke, das Infisical-Web-UI öffne und mit einem Klick die Machine Identity für diesen spezifischen Cluster-Sync rotiere.

Ab diesem Moment ist die Brücke gekappt und das Cluster komplett blind. Der Angreifer kommt von dort aus an keine neuen Daten mehr heran. Ich kann in aller Ruhe im Browser sämtliche Passwörter neu würfeln, während mein Core-Store absolut unangetastet und sicher bleibt. Das ist pragmatisches Risikomanagement.

Natürlich solange nicht mein Infisical Account selber betroffen ist.

Ist es absolut sicher? Nein. Ist dein System absolut sicher? Nein.
Beweis mir das Gegenteil und ein Kaltgetränk deiner Wahl geht auf meinen Nacken!