Das funktioniert oft erstaunlich gut, aber eine Sache hat mich dabei immer wieder gestört:

Die AI vergisst. Also zumindest ab einem gewissen Punkt.

Fairerweise passiert das nicht immer sofort. Es hängt stark vom Modell, vom aktuellen Kontext und vom verfügbaren Context Window ab. Aber auch ein großes Context Window ist nicht unbegrenzt und kann je nach Modell schnell teuer werden.

Natürlich kann ich in einem Chat weiterarbeiten, solange der Kontext noch da ist. Aber spätestens nach ein paar Tagen, einem neuen Fenster, einem anderen Projekt oder einer zusammengefassten Session ist vieles wieder weg.

Was wurde ausprobiert? Welche Entscheidung habe ich getroffen? Warum habe ich diesen einen Workaround genommen und nicht den anderen?

Klar, VSCode und andere IDEs haben inzwischen Memories eingebaut und es gibt genug Projekte, die genau dieses Problem lösen wollen. Für mich fehlte trotzdem etwas, das ich selbst lesen, sortieren und bei Bedarf unterwegs anpassen kann.

Genau dafür nutze ich inzwischen Obsidian als eine Art Session Log. Quasi etwas, was sich mit Notizen und einem Graphen dafür auskennt:

Visualize the relationships between your notes. Find hidden patterns in your thinking through a visually engaging and interactive graph. Source

Warum überhaupt ein Session Log?

Viele Gespräche mit einem AI Agent sind nicht einfach nur “Frage rein, Antwort raus”. Es entsteht nebenbei Kontext:

• Welche Dateien geändert wurden
• Welche Commands gelaufen sind
• Welche Fehler aufgetreten sind
• Welche Annahmen falsch waren
• Welche Idee zwar gut klang, aber nicht funktioniert hat
• Welche Folgeaufgaben offen geblieben sind

Das sind alles Dinge, die später wieder nützlich werden können. Nicht nur für mich, sondern auch für den nächsten AI Agent, der in dem Projekt weiterarbeiten soll. Und ich wechsle immer mal die AI Agents oder auch die Provider dafür (aktuell Cursor).

Statt also alles im Chatverlauf vergammeln zu lassen, speichere ich die wichtigen Teile als Markdown in Obsidian. Das passt gut, weil Obsidian sowieso mein persönliches Notizsystem ist und Markdown einfach kein Spezialformat ist, das in drei Jahren keiner mehr lesen kann. Und so leben dann die Sessions, neben meinen privaten Notizen und unterwegs kann ich so auch die nächste Session beeinflussen.

Wie so eine Session aussieht

Am Ende einer längeren Session kann der Agent eine Zusammenfassung in Obsidian speichern. Die ist nicht einfach ein Chatdump, sondern eher ein kleines Arbeitsprotokoll.

Bei mir besteht so eine Session typischerweise aus:

## Overview

Kurze Zusammenfassung, worum es ging und warum es gemacht wurde.

## Changes

Welche Dateien geändert wurden und was sich fachlich geändert hat.

## Open Points / TODOs

Was noch offen ist oder bewusst nicht erledigt wurde.

## Learnings

Was dabei aufgefallen ist und beim nächsten Mal Zeit sparen kann.

Das klingt erst einmal banal, ist aber sehr hilfreich. Gerade die Abschnitte “Open Points” und “Learnings” sind Gold wert, weil dort nicht nur das Ergebnis steht, sondern auch der Weg dahin.

Was der Agent damit machen kann

Der spannende Teil ist nicht nur, dass ich nach einer Session eine Notiz habe. Spannend wird es, wenn der Agent diese Notizen wieder nutzen kann.

Alte Sessions finden

Wenn ich ein paar Wochen später wieder an einem Thema arbeite, kann der Agent in meinen alten Sessions suchen. Zum Beispiel nach einem Projektnamen, einem Fehlertext oder einem Tool.

Dann muss ich nicht mehr sagen:

Irgendwann hatten wir doch schon mal dieses Problem mit dem Helm Chart…

Stattdessen kann der Agent gezielt in den Session Logs suchen, die passenden Einträge laden und mit dem alten Kontext weiterarbeiten.

Das ist besonders praktisch bei Problemen, die nicht täglich auftreten. Kubernetes, Renovate, Helm Charts, komische CI-Fehler - alles Dinge, bei denen man sehr schnell vergisst, welche Sackgasse man letztes Mal schon ausprobiert hat.

Offene Aufgaben behalten

Nicht jede AI-Session endet sauber mit “fertig”. Manchmal findet man währenddessen Dinge, die später erledigt werden müssen:

• einen Follow-up-Bug
• eine Rechercheaufgabe
• eine technische Schuld
• eine Idee für einen weiteren Blogpost
• einen Test, der noch fehlt
• … oder man hat einfach etwas anderes dazwischen gehabt und aus Versehen die Session gelöscht…

Dafür kann der Agent eigene Session Tasks anlegen. Das sind keine Projekt-Tickets im klassischen Sinne, sondern eher Aufgaben für die AI selbst. Also: “Wenn wir hier weitermachen, vergiss bitte nicht, vorher X zu prüfen.”

Das gefällt mir deutlich besser, als solche Hinweise irgendwo im Chat zu verlieren.

Projektkontext herstellen

Der Agent kann sich zum Start einer Arbeit einen Überblick holen: Welche Projekte gibt es? Welche Session Tasks sind offen? Was wurde zuletzt gemacht?

… und ja manchmal schummel’ ich da eine Aufgabe einfach dazwischen und der AI Agent weiß sofort worum es jetzt gehen wird…

Das ist für mich einer der größten Vorteile. Normalerweise startet ein AI Chat sehr kalt. Ich muss erst wieder erklären, was das Projekt macht, welche Konventionen gelten und warum bestimmte Dinge so sind, wie sie sind. Klar, man könnte dafür auch Rules, Skills und spezielle Agent Prompts nutzen, aber so habe ich halt meine wichtigen Rules und Skills in meinem persönlichen Notizprogramm und kann sie schnell ändern.

Mit den gespeicherten Sessions kann der Agent zumindest einen Teil dieses Kontextes selbst rekonstruieren.

Natürlich ersetzt das kein sauberes README, keine Tests und keine Projektstruktur. Aber es ergänzt sie um etwas, das in Repositories oft fehlt: die Geschichte hinter den Entscheidungen.

Snippets wiederverwenden

Neben Sessions kann der Agent auch kleine Snippets in Obsidian ablegen. Also zum Beispiel einen nützlichen Shell-Befehl, ein Jsonnet-Beispiel oder eine kleine SQL-Abfrage.

Das ist praktisch, weil viele dieser Dinge nicht direkt in ein Projekt gehören, aber trotzdem wiederverwendbar sind. So entsteht mit der Zeit eine kleine persönliche Wissensdatenbank, die nicht nur für mich, sondern auch für die AI durchsuchbar ist.

Warum Obsidian?

Ich hätte dafür natürlich auch irgendeine Datenbank, ein Wiki oder ein spezielles Agent-Memory-Tool nehmen können. Aber Obsidian hat für mich ein paar klare Vorteile:

• Es ist einfach Markdown.
• Ich kann alles selbst lesen und bearbeiten.
• Die Daten liegen bei mir.
• Notizen lassen sich verlinken.
• Und es hat bereits eine Graph Funktion um Verlinkungen untereinander darzustellen
• Es funktioniert auch ohne AI.

Gerade der letzte Punkt ist mir wichtig. Ich möchte kein System bauen, das nur dann nützlich ist, wenn ein bestimmtes Tool gerade funktioniert. Wenn der Agent Mist baut oder das Tool morgen verschwindet, bleiben die Notizen trotzdem brauchbar. Zusätzlich kann ich es unterwegs anpassen und verfeinern. Die wichtigsten Ideen kommen doch auf einer langen Bahnfahrt ohne Internet.

Welche Plugins ich dafür nutze

Obsidian funktioniert schon ohne Plugins sehr gut, aber für diesen Workflow habe ich mir ein paar Erweiterungen installiert, damit es im Alltag nicht nur technisch funktioniert, sondern sich auch gut anfühlt.

Base Board nutze ich, um meine Session Tasks als Kanban anzuzeigen. Die Aufgaben liegen weiterhin als Markdown-Dateien mit Frontmatter im Vault, aber ich kann sie visuell zwischen Spalten verschieben. Genau das ist für AI-Follow-ups praktisch: Aus “das sollten wir später noch prüfen” wird eine sichtbare Karte, die nicht im Chat verschwindet.

Notebook Navigator sorgt dafür, dass alles hübsch und organisiert aussieht. Der normale Datei-Browser von Obsidian ist okay, aber Notebook Navigator erinnert mich an das Beste von Bear: eine klare Seitenleiste, schnelle Orientierung und ein Schreibgefühl, bei dem man nicht ständig das Gefühl hat, in einem Dateisystem herumzuklicken.

Und weil am Ende doch nichts über ein gutes Theme geht, nutze ich Minimal Theme Settings. Das ist kein Muss für den AI-Workflow, aber wenn ich jeden Tag in einem Tool arbeite, möchte ich auch gerne hineinschauen. Gute Typografie und ein ruhiges Theme machen für mich mehr aus, als man zuerst denkt.

Warum selbst gebaut?

Die Verbindung zwischen AI Agent und Obsidian läuft bei mir über einen eigenen MCP. Den habe ich nicht komplett von Hand geschrieben, sondern mir mithilfe von AI bauen lassen.

Das klingt im ersten Moment vielleicht etwas rekursiv, passt aber ziemlich gut: Die AI weiß am besten, wie sie ein Tool benutzen möchte. Welche Parameter hilfreich sind, welche Aktionen häufig gebraucht werden und welche Struktur eine Session haben sollte, merkt man sehr schnell, wenn man den Agent damit arbeiten lässt.

Natürlich hätte ich auch eine etablierte Lösung nehmen können. Aber dann wäre ich wieder an deren Logik und Arbeitsweise gebunden. Ich wollte etwas haben, das ich für meinen eigenen Workflow weiterentwickeln kann. Wenn mir auffällt, dass eine Funktion fehlt, kann ich sie ergänzen. Wenn ein Tool unnötige Roundtrips erzeugt, kann ich es umbauen. Wenn die Session Logs eine bessere Struktur brauchen, ändere ich genau das.

Für mich ist das also weniger ein fertiges Produkt und mehr ein kleines Werkzeug, das mit meinem Arbeitsstil mitwächst.

Wo ich vorsichtig bin

So ein Session Log ist kein magisches Gedächtnis. Man muss trotzdem aufpassen, was gespeichert wird.

Secrets, Tokens oder private Daten gehören dort nicht rein. Auch komplette Chatverläufe speichere ich nicht blind. Für mich funktioniert es besser, wenn die AI am Ende eine strukturierte Zusammenfassung schreibt und ich im Zweifel noch einmal drüber schaue.

Außerdem sollte man den gespeicherten Kontext nicht als Wahrheit behandeln. Nur weil in einer alten Session steht, dass etwas ein guter Ansatz war, heißt das nicht, dass es heute noch stimmt. Versionen ändern sich, Projekte ändern sich und manchmal war die alte Annahme einfach falsch. Aber genau dafür passt Obsidian super, ich ändere das einfach in einem Tool, wo ich Markdown nur als Hilfsmittel nehme.

Mein Fazit

Obsidian als AI Session Log ist für mich ein ziemlich pragmatischer Ansatz. Kein großes Framework, kein kompliziertes Setup, sondern einfach Markdown-Dateien mit brauchbarer Struktur.

Der größte Vorteil ist, dass AI-Arbeit dadurch weniger flüchtig wird. Erkenntnisse verschwinden nicht im Chatverlauf, offene Punkte bleiben sichtbar und der nächste Agent kann sich schneller wieder einarbeiten.

Oder anders gesagt: Ich gebe der AI kein perfektes Gedächtnis, aber wenigstens ein Notizbuch.

Snippets des Monats

grep -v ist die invertierte Suche: Zeigt alle Zeilen, die nicht das angegebene Pattern enthalten. Praktisch, wenn du Noise aus Logs oder Configs filtern willst – etwa alle Debug-Zeilen rauswerfen oder Kommentare ignorieren. Das -v steht für “invert-match” und gehört zu den nützlichsten Flags, wenn du nicht nach etwas suchst, sondern etwas loswerden willst.

grep -v "pattern" file

Technologien des Monats

Dieser Aufruf ermöglicht es, komplexe oder lange Befehle durch kurze, prägnante Abkürzungen zu ersetzen. So kann man effizienter arbeiten und spart wertvolle Zeit bei wiederkehrenden Aufgaben.

Kubernetes

Immer wieder kubectl zu schreiben, birgt Fehlerpotential und natürlich kostet es Zeit. Daher kürze ich in meinem Terminals ‘kubectl’ immer mit k ab.

alias k=kubectl

Und kubectl get wird zu kg.

alias kg='kubectl get'

Die nächsten Abkürzungen würde ich dann nur noch im Codeblock kurz beschreiben, wenn sie nicht selbsterklärend sind:

alias kl='kubectl logs' # Logs bekommen
alias kx='kubectl exec -i -t' # etwas in einem Pod ausführen
alias kgp='kubectl get pod'
alias kgpA='kubectl get pods -A'
alias kgd='kubectl get deployment'
alias kgdA='kubectl get deployments -A'
alias kgs='kubectl get statefulset'
alias kgsA='kubectl get statfulsets -A'
alias kl_f='kubectl logs -f'
alias kl_f_t='kubectl logs -f --tail=200'
alias k_stats='kubectl describe namespace $(kubens -c) && printf "\n" && kubectl get po -o custom-columns="Name:metadata.name,CPU-request:spec.containers[*].resources.requests.cpu,CPU-limit:spec.containers[*].resources.limits.cpu,MEM-request:spec.containers[*].resources.requests.memory,MEM-limit:spec.containers[*].resources.limits.memory"'

Für die letzte Abkürzung muss aber kubens installiert sein und das Ergbnis sieht wie folgt aus:

# Ausgabe für den Namespace Blog
# Name:         blog
# Labels:       kubernetes.io/metadata.name=blog
# Annotations:  <none>
# Status:       Active

# No resource quota.

# No LimitRange resource.

# Name                        CPU-request   CPU-limit   MEM-request   MEM-limit
# blog-blog-8bbc67694-tz9lp   60m           <none>      50Mi          50Mi

Brew

Ich habe das Glück, auch auf Arbeit einen Mac nutzen zu können und da gehört die Paketverwaltung namens Brew einfach dazu. So habe ich auch dafür ein Alias, um die installierten Pakete immer aktuell zu halten:

alias brewup='brew update && brew upgrade && brew outdated && brew cleanup'

Ihr seht also, Terminal-Abkürzungen sind echte Zeitsparer. Sie machen den Alltag nicht nur effizienter, sondern helfen auch dabei, Tippfehler bei langen Befehlen zu vermeiden. Wer regelmäßig Aliases nutzt, wird schnell merken, wie viel flüssiger der Workflow läuft. Falls euch meine Sammlung nützlich ist oder ihr coole Ergänzungen habt, lasst es mich gerne wissen – gemeinsam optimieren wir sie weiter!

Warum zur Hölle kann ich den Admin Account nicht mit einer 2 Faktor Authentifizierung absichern und so geschützter sein?

Nun, da Ghost auf meinem Cluster läuft und dort bereits einige Tools in Kubernetes deployed sind, kann ich einfach den entsprechenden Pfad absichern. Genauer gesagt geht es hier um die Pfade, die mit ghost/* beginnen.

Oauth2-proxy und Tailscale to the rescue

Zuerst möchte ich kurz erklären, was die beiden Tools OAuth2-proxy und Tailscale machen.

OAuth2-proxy

Ich finde die Webseite von OAuth2-Proxy erklärt es sehr gut in einem Satz:

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group. Quelle

Das heißt, durch die Möglichkeit eines Reverse Proxy habe ich die Option, bestimmte Pfade abzusichern und gegen einen (Social) Provider zu authentifizieren. In meinem Fall übernimmt das Gitea. Das bedeutet, dass ab diesem Zeitpunkt bei jedem Aufruf von Pfaden, die mit ghost/* beginnen, geprüft wird, ob ich ein gültiges oauth2-proxy-Token als Cookie habe.

Aber bekanntlich sagt ein Flow Chart mehr als 1000 Worte:

Tailscale

Es gibt einige Programme, die mit der Admin-Api von Ghost umgehen können (z.B. Ulysses). In diesen Programmen kann man dann zum Beispiel solche Beiträge schreiben. Sehr nützlich, aber leider überhaupt nicht kompatibel mit einem OAuth2-Flow. Hier kommt Tailscale ins Spiel. Auch hier wieder die Definition von der Homepage, die für sich spricht:

Tailscale is a mesh VPN (Virtual Private Network) service that streamlines connecting devices and services securely across different networks. It enables encrypted point-to-point connections using the open source WireGuard protocol, which means only devices on your private network can communicate with each other. Unlike traditional VPNs, which tunnel all network traffic through a central gateway server, Tailscale creates a peer-to-peer mesh network (known as a tailnet). However, you can still use Tailscale like a traditional VPN by routing all traffic through an exit node. Quelle

Umgangssprachlich: Man baut einen direkten VPN-Tunnel zu dem Dienst in Kubernetes auf. Diesen Tunnel kann man aber erst aufbauen, wenn man sich auch im Tailscale VPN eingeloggt hat. Ab diesem Zeitpunkt kann man aber ganz normal auf der Seite surfen. Um das zu ermöglichen, bekommt man von Tailscale eine eigene Domain dafür. D.h. man hat dann eine öffentliche URL (in diesem Fall timmmi.de) und man hat eine “private/interne” URL.

Umsetzung

Genug der Theorie, jetzt komme ich zu dem Teil, wo ich es implementiert habe.

Um den geneigten Leser nicht zu sehr zu langweilen, gehe ich an dieser Stelle davon aus, dass der OAuth2-Proxy und Tailscale deployed sind. Das heißt, ich werde nur noch die Details für die richtigen Ingresse in Kubernetes erklären. Nur als Hinweis:

Für OAuth2-Proxy habe ich diesen Helm Chart genutzt

und für Tailscale dieses:

Insgesamt braucht ich 3 Ingresse:

1. ein Ingress, der die Domain und den Pfad ghost/* auf einen OAuth2 Endpunkt weiterleitet
2. ein Ingress, der diesen OAuth2 Endpunkt bereitstellt
3. ein Ingress, der den Service von Ghost im Tailscale Netzwerk bereitstellt

⠀ Da ich so etwas vielleicht öfter machen möchte, habe ich es der Einfachheit halber in Jsonnet geschrieben.

In diesem Fall habe ich eine Hauptdatei, wo ich definiere, was ich haben will, und ich habe eine Bibliotheksdatei, die die Logik darstellt:

local o = import 'secure-ingresses.libsonnet';
local ingresses = [
  {
    name: 'ghost-admin',
    namespace: 'ghost',
    domain: 'timmmi.de',
    service: {
      name: 'ghost-ghost',
      port: 2368,
    },
    need: {
      origin: true,
      oauth2: true,
      tailscale: true,
    },
    path: '/ghost/',
    secretName: 'ghost-cert-tls',
  },
];
o.createIngresses(ingresses)

secure-ingresses.jsonnet oder auch die Hauptdatei

Durch das need kann ich beeinflussen, ob ein “normaler”, ein oauth2 oder/und ein tailscale Ingress erstellt wird.

local nginxIngressClassName = 'nginx';
local tailscaleIngressClassname = 'tailscale';
local oauth2Namespace = 'oauth2-proxy';
local certManagerClusterIssuer = 'clusterIssuer';

local originIngress(ingress) = {
  apiVersion: 'networking.k8s.io/v1',
  kind: 'Ingress',
  metadata: {
    name: std.asciiLower(ingress.name) + '-oauth2',
    annotations: {
      'cert-manager.io/cluster-issuer': certManagerClusterIssuer,
      'nginx.ingress.kubernetes.io/auth-signin': 'https://$host/oauth2/start?rd=$escaped_request_uri',
      'nginx.ingress.kubernetes.io/auth-url': 'https://$host/oauth2/auth',
    },
    namespace: ingress.namespace,
  },
  spec: {
    ingressClassName: nginxIngressClassName,
    rules: [
      {
        host: ingress.domain,
        http: {
          paths: [
            {
              backend: {
                service: {
                  name: ingress.service.name,
                  port: {
                    number: ingress.service.port,
                  },
                },
              },
              path: ingress.path,
              pathType: 'Prefix',
            },
          ],
        },
      },
    ],
    tls: [
      {
        hosts: [
          ingress.domain,
        ],
        secretName: ingress.secretName,
      },
    ],
  },
};

local oauth2Ingress(ingress) = {
  apiVersion: 'networking.k8s.io/v1',
  kind: 'Ingress',
  metadata: {
    name: std.asciiLower(ingress.name) + '-oauth2-endpoint',
    annotations: {
      'cert-manager.io/cluster-issuer': certManagerClusterIssuer,
    },
    namespace: oauth2Namespace,
  },
  spec: {
    ingressClassName: nginxIngressClassName,
    rules: [
      {
        host: ingress.domain,
        http: {
          paths: [
            {
              backend: {
                service: {
                  name: 'oauth2-proxy',
                  port: {
                    number: 80,
                  },
                },
              },
              path: '/oauth2',
              pathType: 'Prefix',
            },
          ],
        },
      },
    ],
    tls: [
      {
        hosts: [
          ingress.domain,
        ],
        secretName: ingress.secretName,
      },
    ],
  },
};

local tailscaleIngress(ingress) = {
  apiVersion: 'networking.k8s.io/v1',
  kind: 'Ingress',
  metadata: {
    name: std.asciiLower(ingress.name) + '-tailscale',
    namespace: ingress.namespace,
  },
  spec: {
    ingressClassName: tailscaleIngressClassname,
    rules: [
      {
        http: {
          paths: [
            {
              backend: {
                service: {
                  name: ingress.service.name,
                  port: {
                    number: ingress.service.port,
                  },
                },
              },
              path: ingress.path,
              pathType: 'Prefix',
            },
          ],
        },
      },
    ],
    tls: [
      {
        hosts: [
          std.asciiLower(ingress.name),
        ],
      },
    ],
  },
};

local createIngresses(ingresses) = std.flattenArrays([
  [
    if ingress.need.origin then originIngress(ingress),
    if ingress.need.oauth2 then oauth2Ingress(ingress),
    if ingress.need.tailscale then tailscaleIngress(ingress),
  ]
  for ingress in ingresses
]);

{
  originIngress: function(ingress) originIngress(ingress),
  oauth2Ingress: function(ingress) oauth2Ingress(ingress),
  tailscaleIngress: function(ingress) tailscaleIngress(ingress),
  createIngresses: function(ingresses) createIngresses(ingresses),
}

secure-ingresses.libsonnet oder auch die Bibliotheksdatei

Da meine HTTP-Zertifikate im Cluster mit dem CertManager erzeugt werden, sind die richtigen Annotationen direkt enthalten. Der Tailscale Ingress bildet die HTTPs im VPN-Netzwerk ab und liefert eigene Zertifikate aus. D.h. hier wird der CertManager nicht benötigt.

Lässt man das Ganze rendern, erhält man folgendes Ergebnis:

jsonnet secure-ingresses.jsonnet| jq -c '.[]' | while read -r item; do echo "$separator"; echo "$item" | yq -P; separator="—"; done

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: clusterIssuer
    nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri
    nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth
  name: ghost-admin-oauth2
  namespace: ghost
spec:
  ingressClassName: nginx
  rules:
    - host: timmmi.de
      http:
        paths:
          - backend:
              service:
                name: ghost-ghost
                port:
                  number: 2368
            path: /ghost/
            pathType: Prefix
  tls:
    - hosts:
        - timmmi.de
      secretName: ghost-cert-tls
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: clusterIssuer
  name: ghost-admin-oauth2-endpoint
  namespace: oauth2-proxy
spec:
  ingressClassName: nginx
  rules:
    - host: timmmi.de
      http:
        paths:
          - backend:
              service:
                name: oauth2-proxy
                port:
                  number: 80
            path: /oauth2
            pathType: Prefix
  tls:
    - hosts:
        - timmmi.de
      secretName: ghost-cert-tls
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ghost-admin-tailscale
  namespace: ghost
spec:
  ingressClassName: tailscale
  rules:
    - http:
        paths:
          - backend:
              service:
                name: ghost-ghost
                port:
                  number: 2368
            path: /ghost/
            pathType: Prefix
  tls:
    - hosts:
        - ghost-admin

Gerenderte Yaml Datei, die so in den Kubernetes Cluster deployed werden könnte

Nach dem erfolgreichen Deployment, muss ich mich erst authentifizieren, wenn ich die URL https://example.com/ghost/#/ ansurfe. So bleibt die Administrationsoberfläche geschützt.

Fazit

Mit 2 zusätzlichen Tools, und 3 Ingressen kann man das Admininterface von Ghost ausreichend absichern. Was ich mir allerdings wünschen würde, wäre eine native Lösung von Ghost. Dies wird zumindest auch im Forum immer wieder gefragt und dann nie zufriedenstellend beantwortet:

Reddit Kommentar

Immerhin gibt es mit diesem Post und einigen Commits auf Github ein wenig Hoffnung:

Dann hoffe ich weiter…

Source

Doch keine Panik, ich bin gerade die letzten 2h durch diese Problematik gegangen und habe nun einen guten dokumentierten Weg (auf Englisch), den ihr gerne befolgen könnt:

The Workaround

At first I found a workaround, add this to your helm chart custom values:

#...
mysql:
  enabled: true
#...
  auth:
#...
    authenticationPolicy: "mysql_native_password"
  primary:
    configuration: |-
        [mysqld]
        authentication_policy='{{- .Values.auth.authenticationPolicy | default "* ,," }}'
        mysql_native_password=ON
        skip-name-resolve
        explicit_defaults_for_timestamp
        basedir=/opt/bitnami/mysql
        plugin_dir=/opt/bitnami/mysql/lib/plugin
        port={{ .Values.primary.containerPorts.mysql }}
        mysqlx={{ ternary 1 0 .Values.primary.enableMySQLX }}
        mysqlx_port={{ .Values.primary.containerPorts.mysqlx }}
        socket=/opt/bitnami/mysql/tmp/mysql.sock
        datadir=/bitnami/mysql/data
        tmpdir=/opt/bitnami/mysql/tmp
        max_allowed_packet=16M
        bind-address=*
        pid-file=/opt/bitnami/mysql/tmp/mysqld.pid
        log-error=/opt/bitnami/mysql/logs/mysqld.log
        character-set-server=UTF8
        slow_query_log=0
        long_query_time=10.0

        [client]
        port={{ .Values.primary.containerPorts.mysql }}
        socket=/opt/bitnami/mysql/tmp/mysql.sock
        default-character-set=UTF8
        plugin_dir=/opt/bitnami/mysql/lib/plugin

        [manager]
        port={{ .Values.primary.containerPorts.mysql }}
        socket=/opt/bitnami/mysql/tmp/mysql.sock
        pid-file=/opt/bitnami/mysql/tmp/mysqld.pid
    persistence:
#...

What does that do?

It resets the authentication_policy back to mysql_native_password. To do this, we must then set an additional option in mysql.conf, mysql_native_password=ON. Therefore, the default config was overwritten with all its default options and this value was added.

Why did this happen?

The latest Ghost Helm version also uses a new MySQL chart version from Bitnami, where a breaking change regarding authentication has been introduced. Or rather, a long announced deprecation was removed.

Source

This major bump uses mysql 8.4 image, that includes several configuration settings, for example the parameter auth.defaultAuthenticationPlugin has been removed in favor of auth.authenticationPolicy. This could potentially break your deployment and you would need to adjust the config settings accordingly.

Related notes in the deprecation removal in mysql: Deprecation Removal MySQL 8.4

And what happens now aka Solution?

With the above options, the mysql pod will start again and so will Ghost. At this point you should make a backup of your posts at the latest. From this point onwards, you can upgrade to the new authentication method. Follow this guide: https://dnsmichi.at/2024/05/11/docker-compose-ghost-msql-8-4-msql-native-password-startup-errors-mitigation-solution/#how-to-migrate-to-cachingsha2password

I am currently trying this out and will then update this comment with the specific commands.

Edit: mysql-0 is the name of pod running mysql

kubectl exec -it mysql-0 – bash # connect into the pod with an interactive shell
mysql -u root -p # enter root password afterwards, you will find this information the related secret in your cluster

mysql> SELECT User, Host, plugin FROM mysql.user;
+------------------+-----------+-----------------------+
| User             | Host      | plugin                |
+------------------+-----------+-----------------------+
| bn_ghost         | %         | mysql_native_password |
| root             | %         | mysql_native_password |
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | caching_sha2_password |
| mysql.sys        | localhost | caching_sha2_password |
+------------------+-----------+-----------------------+
5 rows in set (0.00 sec)

Now we change to the new authentication method: caching_sha2_password. But you should dump your database before! Open another terminal for the next command.

kubectl exec -it mysql-0 – /bin/sh -c  "mysqldump -u root -p<EnterPasswordHereWithoutALeadingSpace> --databases <EnterDatabaseNameHere>" >dump.sql

Now go back to the previous terminal. The authentication method will now be changed.

mysql> ALTER USER 'root'@'%' IDENTIFIED WITH caching_sha2_password BY '<EnterYourPasswordForRootHere>';
Query OK, 0 rows affected, 1 warning (0.05 sec)
mysql>  ALTER USER 'bn_ghost'@'%' IDENTIFIED WITH caching_sha2_password BY 'EnterYourPasswordForbn_ghostHere';
Query OK, 0 rows affected, 1 warning (0.02 sec)
mysql> SELECT User, Host, plugin FROM mysql.user;
+------------------+-----------+-----------------------+
| User             | Host      | plugin                |
+------------------+-----------+-----------------------+
| bn_ghost         | %         | caching_sha2_password |
| root             | %         | caching_sha2_password |
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | caching_sha2_password |
| mysql.sys        | localhost | caching_sha2_password |
+------------------+-----------+-----------------------+
5 rows in set (0.00 sec)

Now you can exit mysql and exit the pod and remove the options added above regarding the mysql_native_password and restart your helm deployment and cross your fingers. (remove mysql.auth.authenticationPolicy and mysql.primary.configuration)

First the mysql pod should restart and become healthy with the livenessProbe. Then the deployment of ghost should be restarted, as it is probably currently in a crash loop. After the initialization is done and this pod is also healthy, your Ingress should work again and the blog should be accessible without data loss. If something went wrong, you should now have the dump of your MySQL and the exported blog posts. You can now start from a fresh state.

Diesen Kommentar habe ich auch in das bereits geöffnete Issue gepostet. Ich bin gespannt, ob Bitnami, die Hersteller des Charts, noch etwas in die neueren Versionen des Charts übernehmen, damit dieser Migrationspfad etwas smoother wird.