# ESO Upgrade Plan — DMZ K3s / IT15 ArgoCD Stand: 2026-06-19 12:45 UTC ## Ziel External Secrets Operator in der DMZ sauber aus dem alten Stand `0.10.5` herausfuehren, ohne laufende Infisical-Secret-Synchronisation fuer PIDOKA-Apps zu gefaehrden. ## Aktueller Zustand - Deployment: IT15-ArgoCD Application `platform-external-secrets`. - Zielcluster: DMZ K3s `192.168.20.40`. - Kubernetes Server Version: `v1.28.4+k3s2`. - ESO Chart/Image: `0.10.5`. - ArgoCD Status: `platform-external-secrets` ist `Synced / Degraded`. - ESO live: - Controller, Webhook und Cert Controller laufen. - Alle `SecretStore/dmz-infisical`: `Ready=True`, `Valid`. - Alle `ExternalSecret`: `Ready=True`, `SecretSynced`. - Aktuelle ESO Custom Resources im GitOps-Repo: - Alle `SecretStore` und `ExternalSecret` nutzen `external-secrets.io/v1beta1`. - Keine ESO Generator-Objekte im GitOps-Repo gefunden. - Keine ESO Generator-Objekte live im Cluster gefunden. ## Root Cause fuer aktuelles Degraded ArgoCD markiert mehrere ungenutzte ESO Generator-CRDs als `Degraded`, weil deren `NamesAccepted` Condition `False` ist: - `acraccesstokens.generators.external-secrets.io` - `ecrauthorizationtokens.generators.external-secrets.io` - `fakes.generators.external-secrets.io` - `gcraccesstokens.generators.external-secrets.io` - `githubaccesstokens.generators.external-secrets.io` - `passwords.generators.external-secrets.io` - `uuids.generators.external-secrets.io` - `vaultdynamicsecrets.generators.external-secrets.io` Meldung: `CRD names have not been accepted: "" is already in use`. Bewertung: Die Infisical-basierte Secret-Synchronisation ist aktuell nicht betroffen. Das Problem ist ein CRD-/Health-Thema, nicht ein Secret-Sync-Ausfall. ## Recherchebasis - ESO Stability/Support: - `0.10.x` ist EOL seit 2024-12-24. - ESO empfiehlt Upgrades version-by-version statt grosser Spruenge. - ESO empfiehlt Tests in non-production vor Upgrade. - Quelle: https://external-secrets.io/latest/introduction/stability-support/ - Aktuelle Releases: - GitHub zeigt `v2.6.0` / Helm Chart `2.6.0` als aktuelle Linie im Juni 2026. - Quelle: https://github.com/external-secrets/external-secrets/releases - Aktuelle Chart-Werte: - `installCRDs: true` ist vorhanden. - Aktuelle Chart-Linie hat granularere `crds.*` und `process*` Optionen als `0.10.5`. - `v1beta1` serving ist in aktueller Linie nur noch als unsicherer Backward-Compatibility-Pfad vorgesehen und deprecated. - Quelle: https://raw.githubusercontent.com/external-secrets/external-secrets/helm-chart-2.6.0/deploy/charts/external-secrets/values.yaml - ESO Generatoren: - Generatoren werden ueber `sourceRef.generatorRef` genutzt. - In unserem GitOps-Repo und Cluster ist keine Generator-Nutzung vorhanden. - Quelle: https://external-secrets.io/latest/guides/generator/ ## Zentrale Risiken 1. DMZ-K3s ist mit `v1.28.4+k3s2` alt. - Die aktuelle ESO-Supportmatrix nennt fuer die 2.x-Linie deutlich neuere Kubernetes-Versionen. - Direktes Upgrade auf `2.6.0` ohne K3s-Upgrade waere nicht sauber supportbar. 2. Unsere ESO-Manifeste sind `v1beta1`. - Aktuelle ESO-Linie zielt auf `external-secrets.io/v1`. - Vor einem grossen ESO-Upgrade muessen `SecretStore` und `ExternalSecret` im GitOps-Repo auf `v1` migriert und live verifiziert werden. 3. CRDs sind clusterweit. - Fehlerhafte CRD-Aenderungen koennen alle ESO-Nutzer betreffen. - CRD-Loeschungen sind nicht der bevorzugte Weg, solange wir keinen getesteten Rollback haben. 4. Secret-Verfuegbarkeit. - Wenn ESO ausfaellt, bleiben bestehende Kubernetes Secrets zunaechst vorhanden, aber Rotation/Refresh stoppt. - Vor Upgrade muessen wichtige live Secrets und App-Readiness verifiziert werden. ## Empfohlener Upgrade-Pfad ### Phase 0 — Keine Sofort-Aenderung an ESO Status: empfohlen. - `platform-external-secrets` trotz `Degraded` nicht blind reparieren. - Laufende Secret-Sync-Funktion weiter beobachten. - Optional: rein kosmetische Health-Customization nur dann, wenn der rote ArgoCD-Status operativ stoert. Exit-Kriterium: - Alle aktuellen `ExternalSecret` und `SecretStore` bleiben `Ready=True`. ### Phase 1 — Preflight und Backup Read-only plus dokumentierend, vor jeder schreibenden Aenderung. - Export aller ESO CRDs: - `externalsecrets.external-secrets.io` - `secretstores.external-secrets.io` - `clustersecretstores.external-secrets.io` - `pushsecrets.external-secrets.io` - Generator-CRDs - Export aller ESO Custom Resources ohne Secretwerte: - `SecretStore` - `ExternalSecret` - ggf. `ClusterSecretStore`, `PushSecret`, Generatoren - Export der ArgoCD Application `platform-external-secrets`. - Snapshot der relevanten GitOps-Dateien. - Live-Readiness erfassen: - ESO Deployments/Pods - SecretStores - ExternalSecrets - PIDOKA App Health Exit-Kriterium: - Backup-/Inventarordner mit Checksums liegt lokal vor. - Kein Secretwert wurde dokumentiert. ### Phase 2 — API-Migration im GitOps-Repo von `v1beta1` auf `v1` Ziel: Manifeste vorbereiten, bevor eine ESO-Version kommt, die `v1beta1` nicht mehr sauber bedienen soll. - Alle GitOps-Dateien unter `tenants/pidoka/prod/*/external-secrets/` von: - `apiVersion: external-secrets.io/v1beta1` - nach `apiVersion: external-secrets.io/v1` - Betroffene Ressourcen: - 5 `SecretStore` - 8 `ExternalSecret` - Vor Apply: - Server-side dry-run gegen aktuellen Cluster pruefen. - Falls aktuelles `0.10.5` `v1` noch nicht served, diese Phase erst nach Zwischenupgrade ausfuehren. Exit-Kriterium: - GitOps rendert sauber. - `kubectl apply --dry-run=server` ist gruen oder es ist klar dokumentiert, welcher Zwischenstand zuerst erforderlich ist. ### Phase 3 — K3s-Kompatibilitaetsentscheidung Empfohlen vor ESO 2.x. - DMZ-K3s Upgrade separat planen. - Ziel: Kubernetes-Version auf eine von aktueller ESO-Linie unterstuetzte Version bringen. - Das ist ein eigenes Infrastruktur-Change mit eigenem Backup-/Rollback-Plan. Exit-Kriterium: - K3s-Zielversion festgelegt. - Longhorn/Traefik/App-Kompatibilitaet geprueft. - Separates OK fuer K3s-Upgrade liegt vor. ### Phase 4 — ESO Zwischenupgrade oder Zielupgrade Option A, konservativ: - Upgrade in kleinen Schritten gemaess ESO-Empfehlung. - Nach jeder Stufe: - ESO Pods Ready - Webhook Ready - SecretStores Valid - ExternalSecrets SecretSynced - ArgoCD Sync/Health pruefen Option B, erst nach K3s-Upgrade: - Direkt auf aktuelle unterstuetzte Linie, z.B. Chart `2.6.0`, aber nur wenn: - Kubernetes-Version passt, - `v1` Manifeste vorbereitet sind, - Release Notes geprueft wurden, - CRD-Diff vorab analysiert ist. Exit-Kriterium: - `platform-external-secrets` ist `Synced / Healthy`. - Alle App-Secrets bleiben vorhanden. - Alle PIDOKA Apps bleiben `Healthy`. ### Phase 5 — Cleanup Nur mit separatem OK. - Ungenutzte alte CRD-Versionen oder Generator-CRDs nur entfernen, wenn: - keine Objekte existieren, - aktuelle Chart-Linie sie nicht mehr braucht, - Rollback klar ist. - ArgoCD `ignoreDifferences` fuer `caBundle` beibehalten, wenn weiterhin controllerverwaltet. ## Rollback-Prinzip - GitOps-Rollback auf vorherigen Commit. - ESO Chart-Version zurueck auf letzte funktionierende Version. - CRD-Rollback nicht leichtfertig: CRDs nur mit vorherigem Export und kontrollierter Sequenz veraendern. - Bestehende Kubernetes Secrets bleiben waehrend ESO-Ausfall erhalten; Apps sollten dadurch nicht sofort ausfallen, aber Secret-Refresh stoppt. ## Konkrete naechste Empfehlung Nicht sofort ESO 2.x installieren. Naechster sinnvoller Schritt: 1. Phase 1 Preflight/Backup read-only erstellen. 2. Danach server-side dry-run fuer `v1` API-Migration pruefen. 3. Danach entscheiden: - Wenn `v1` unter aktuellem `0.10.5` nicht geht: erst kontrollierter Zwischenupgrade. - Wenn `v1` geht: GitOps API-Migration separat ausrollen. 4. K3s-Upgrade als Voraussetzung fuer aktuelle ESO-2.x-Linie separat planen. ## Needs OK - OK fuer Phase 1 ist risikoarm, read-only/dokumentierend. - OK fuer Phase 2 GitOps-Aenderung separat. - OK fuer jedes echte ESO-/K3s-Upgrade separat.