# Altes ArgoCD Repo Audit — `GitMasterOne/ArgoCD` — 2026-06-15 Ziel: Vor Migration ins neue `platform-gitops` Repo Struktur, Helm/YAML-Mix und Secret-Risiken verstehen. Keine Secretwerte absichtlich ausgegeben. Eine erste Live-Secret-Abfrage gab kurz Base64-Werte aus; die gespeicherte Audit-Datei wurde sofort durch eine sanitisierte Variante ersetzt und enthält nur noch Secret-Namen/Key-Namen. ## Repo-Stand - Repo: `https://github.com/GitMasterOne/ArgoCD.git` - Branch: `main` - Commit: `8882e3c3a9f0414c0fa9f22772a798f1c2be8155` - Dateien: 31 - ArgoCD Applications im Repo: 5 ## Struktur-Mix | App | Quelle | Typ | Besonderheit | | --- | --- | --- | --- | | `apps` | `applications/` | App-of-apps | Verwaltet alte DMZ-ArgoCD Applications, `prune/selfHeal` aktiv. | | `n8n` | `applications/n8n.yaml` | Externes Helm Chart | Chart `8gears.container-registry.com/library/n8n`, Values inline in Application. | | `hf-mautic` | `applications/hf-mautic.yaml` + `charts/mautic` | Lokales Helm Chart + zusätzlich inline `valuesObject` | Doppelte/uneinheitliche Wertequellen; Secrets referenziert via `existingSecret`. | | `hf-espocrm` | `espocrm/` | Lokales Helm Chart | Values split in `values.yaml` und `values-mariadb.yaml`; Klartext-Passwörter gefunden. | | `suitecrm` | `charts/suitecrm` | Lokales Helm Chart | Klartext-/Placeholder-Passwörter in `values.yaml`; eigenes Secret-Template. | ## Secret-/Token-Befund Maskierter Scan: - 9 Passwort-Verdachtsstellen insgesamt. - Kritisch für Migration: - `espocrm/values.yaml` enthält DB-Passwort im Values-File. - `espocrm/values-mariadb.yaml` enthält MariaDB Root/User Passwort im Values-File. - `charts/suitecrm/values.yaml` enthält Admin-/MariaDB-Passwort-Felder; teils offenbar echte oder Platzhalterwerte, müssen aus Git raus. - Keine GitHub PATs, Private Keys oder JWTs im Repo-Scan gefunden. - `n8n` nutzt Live-Secret `n8n-secret` mit Keys `BASIC_AUTH_PASSWORD`, `BASIC_AUTH_USER`, `ENCRYPTION_KEY`; Werte nicht dokumentieren. ## Inkonsistenzen / Migrationsrisiken 1. Unterschiedliche ArgoCD-Application-Stile: - App-of-apps - lokaler Chart-Pfad - externes Helm-Chart - inline Helm Values - valueFiles - valuesObject 2. Alte Applications zeigen auf `https://kubernetes.default.svc`, weil sie im alten DMZ-ArgoCD laufen. Im neuen IT15-ArgoCD müssen sie auf `https://192.168.20.40:6443` zeigen. 3. Alle alten Apps laufen im Project `default`; im neuen Modell müssen sie nach `tenant-pidoka` oder `platform`. 4. `hf-mautic` hat sowohl Chart-Defaults als auch inline `valuesObject`; Migration muss tatsächliche live-gerenderte Werte prüfen. 5. `espocrm` und `suitecrm` dürfen nicht 1:1 übernommen werden, bevor Secrets ausgelagert sind. 6. `n8n` ist strukturell am saubersten: externes Chart, Secrets bereits als Kubernetes Secret referenziert, PVC Longhorn 5Gi, Ingress klar. ## Artefakte - `repo-info.txt` — Repo/Branch/Commit - `file-list.txt` — Dateiliste - `yaml-list.txt` — YAML/Chart-Liste - `structure-classification.tsv` — Klassifikation nach Datei/Typ - `argocd-app-yaml-summary.tsv` — Application-Quelle/Zielübersicht - `secret-scan-summary.md` — maskierte Secret-Fundstellen - `secret-scan-findings.json` — maschinelle maskierte Findings - `masked-key-files.txt` — maskierte Ausschnitte relevanter Dateien - `hf-n8n-live-metadata.txt` — sanitisierte Live-Metadaten zu n8n ## Empfehlung Nicht das alte Repo direkt reorganisieren. Stattdessen App-für-App in `platform-gitops` neu modellieren. Erster Kandidat bleibt `n8n`, aber vor Cutover: 1. `n8n` Values aus alter Application sauber in `tenants/pidoka/stage/n8n/` übernehmen. 2. Secret-Quelle definieren: `n8n-secret` nach Infisical/ExternalSecret-Modell migrieren oder bestehendes Secret zunächst referenzieren. 3. IT15-ArgoCD Application im Project `tenant-pidoka` mit Ziel `https://192.168.20.40:6443`, Namespace `hf-n8n` vorbereiten. 4. Vor Sync prüfen, ob altes DMZ-ArgoCD die gleiche Ressource noch verwaltet — Doppelverwaltung vermeiden. 5. Cutover nur mit explizitem OK. ## Update — Git-History Secret Scan — 2026-06-15 19:26 UTC Zusätzlich zur aktuellen Repo-Version wurde die Git-History gescannt. - Commits gescannt: 174 - Maskierte eindeutige Verdachtsfunde: 102 - Kategorien: - `password`: 86 - `token_or_key`: 16 - Keine GitHub PATs, Private Keys oder JWTs gefunden. - Relevante historische Altlasten: - Frühere `n8n`-Varianten enthielten offenbar Passwortwerte direkt in `applications/n8n.yaml` bzw. `charts/n8n/values.yaml`. - Frühere `mautic`-Values enthielten DB-Passwortfelder direkt in `charts/mautic/values.yaml`. - Frühere `espocrm`-Versionen enthielten ein `espocrm-db-secret.yaml` und vendored MariaDB-Chart-Dateien mit vielen Secret-/Password-Feldern. - Aktuelle Version enthält weiterhin Passwort-Verdachtsstellen in `espocrm/values*.yaml` und `charts/suitecrm/values.yaml`. Konsequenz: - Das alte Repo ist nicht nur in der aktuellen Version, sondern auch in der Git-History als potenziell secret-belastet zu behandeln. - Keine direkte Übernahme der Git-History ins neue Repo. - Werte aus altem Repo nicht vertrauen; Secrets müssen aus Live-Cluster/Infisical/neuem Recovery-Prozess sauber rekonstruiert werden. - Falls das alte Repo öffentlich war/ist oder breiter Zugriff bestand: betroffene Passwörter rotieren, insbesondere n8n Basic Auth/Encryption Key, Mautic DB/Redis, EspoCRM DB, SuiteCRM Admin/DB. ## Normalisierungsziel für `platform-gitops` Für jede App im neuen Repo ein einheitliches Muster: ```text tenants//// application.yaml # ArgoCD Application, Zielcluster/Project/Namespace values.yaml # nicht-sensitive Helm Values external-secrets.yaml # Infisical/ExternalSecret Referenzen, keine Werte kustomization.yaml # optional, wenn mehrere Manifeste README.md # App-spezifische Hinweise, Rollback, Ingress, PVC ``` Regeln: 1. Keine Secretwerte in Git, auch nicht Base64. 2. Keine Secret-History übernehmen. 3. ArgoCD Applications zeigen im neuen ArgoCD auf `https://192.168.20.40:6443`, nicht `https://kubernetes.default.svc`. 4. Project-Zuordnung zwingend: `tenant-pidoka`, `tenant-cattaro`, `platform`. 5. Externe Helm Charts bleiben erlaubt, aber Values werden als Datei normalisiert, nicht inline in Application-YAML. 6. Lokale Charts nur übernehmen, wenn sie vorher secret-bereinigt und strukturell geprüft sind. 7. Erst read-only diff/render, dann Sync/Cutover mit explizitem OK.