# IT15 Management-K3s + Argo CD + Infisical PIDOKA — Arbeitsplan

Stand: 2026-06-13
Owner-Kontext: Mislav / K3s DMZ / IT15 Management-Rechner

## Verbindliche Linie

- Ziel ist, Argo CD und Infisical so schnell wie sauber möglich außerhalb der DMZ zu betreiben.
- IT15 wird Management-Rechner.
- Auf IT15 wird ein kleiner One-Node-K3s-Management-Cluster aufgebaut.
- Neues Argo CD wird auf diesem IT15-Management-K3s installiert.
- Bestehendes Argo CD in der DMZ bleibt zunächst unverändert als Ist-System, bis Migration validiert ist.
- DMZ-K3s bleibt Runtime-/Zielcluster.
- Infisical bleibt außerhalb der DMZ und wird minimal für PIDOKA genutzt; keine Vorratsstruktur.
- Key-/Secret-Pfad wird von Anfang an sauber aufgebaut: keine Admin-Kubeconfigs in Git/Chat, keine globalen Tokens.
- Vor echten Secret-/Argo-Migrationsschritten: frisches Infisical-Backup + Restore-Test als Gate.
- Pilotdeployment zuerst mit unkritischer Anwendung.

## Zielarchitektur

- IT15: Management-Zone
  - One-Node-K3s
  - Argo CD Control Plane
  - Infisical außerhalb DMZ
- DMZ-K3s:
  - Runtime-/Zielcluster
  - Workloads, Ingress, Storage
  - nur eingeschränktes Argo-CD-RBAC für benötigte Namespaces
- DiskStation:
  - Backup/Restore/NAS
  - kein Argo-CD-Betrieb

## Phasen

### Phase 0 — IT15 Zugriff und Preflight

Ziel: IT15 sicher als Management-Host vorbereiten.

Prüfen:
- Remote-/SSH-Zugriff für kube-bot oder freigegebener Admin-Pfad.
- CPU/RAM/Disk.
- WSL/Linux-Zustand oder native Linux-Option.
- Docker/Infisical-Zustand nur lesend.
- Netzwerkpfad IT15 -> DMZ Kubernetes API.
- Firewall-/Portbedarf minimal halten.

### Phase 1 — Infisical Backup/Restore Gate

Ziel: Infisical ist vor Secret-Pilot abgesichert.

Gate:
- Frisches Backup.
- Isolierter Restore-Test erfolgreich.
- Keine Secrets in Chat/Logs.
- Nur PIDOKA-Struktur, keine Vorratsprojekte.

### Phase 2 — One-Node-K3s auf IT15 installieren

Nur nach explizitem OK.

Ziel:
- Kleiner Management-K3s auf IT15.
- Kein öffentlicher Zugriff.
- Kubeconfig geschützt.
- Basischecks: Node Ready, CoreDNS, local-path oder bewusst gewählter Storage.

### Phase 3 — Neues Argo CD auf IT15-K3s installieren

Nur nach explizitem OK.

Ziel:
- Argo CD offiziell im Management-K3s installieren.
- UI/API nur intern erreichbar.
- Admin-Credentials sicher behandeln.
- Keine produktiven Secrets vor Backup/Restore-Gate.

### Phase 4 — DMZ-K3s als Zielcluster anbinden

Ziel:
- Eingeschränkter ServiceAccount/RBAC im DMZ-K3s.
- Anfangs nur Pilot-Namespace.
- Keine breite Cluster-Admin-Kubeconfig als Dauerlösung.
- Zugriff von IT15 zur DMZ API kontrolliert.

### Phase 5 — Pilotdeployment

Ziel:
- Unkritische Anwendung über neues IT15-Argo-CD ausrollen.
- Optional synthetisches Testsecret über Infisical.
- Sync, Health, Drift, Rollback prüfen.
- Keine Auswirkungen auf bestehende Produktiv-Apps.

### Phase 6 — Migration bestehender Deployments

Erst nach erfolgreichem Pilot:
- AppProjects/Mandantentrennung definieren.
- PIDOKA-Deployments priorisieren.
- Secrets schrittweise nach Infisical migrieren.
- Altes DMZ-Argo-CD erst nach Parallelbetrieb und Rollback-Gate deaktivieren.

## Offene Entscheidungen

- IT15 technischer Unterbau: WSL2-K3s vs. native Linux/VM.
- Pilot-App auswählen.
- Exakter RBAC-Scope für Pilot-Namespace.
- Git-Repository-Struktur für neue Argo-CD-Apps.
- Infisical PIDOKA-Projekt-/Pfadstruktur minimal festlegen.

## Nicht ohne explizites OK

- Installation auf IT15.
- Änderung an bestehendem DMZ-Argo-CD.
- Anlegen produktiver Secrets.
- Kubeconfig-/Token-Export.
- Löschen/Deaktivieren alter Argo-CD-Komponenten.

## Preflight Findings — 2026-06-13 05:50 UTC

Read-only checks:

- Infisical on IT15 reachable from kube-bot runtime: `http://192.168.1.121:8088/api/status` returns `Ok`.
- DMZ K3s API on control-plane `192.168.20.40:6443` is reachable from kube-bot runtime.
- Worker `192.168.20.45:6443` refused connection; expected if API is only on control-plane.
- Existing DMZ Argo CD is running in namespace `infra-argocd`.
- Existing DMZ Argo CD has ingress `argocd.cattaro.eu` via Traefik.
- Existing Argo CD apps mostly use `default` AppProject.
- DMZ node could not reach Infisical on IT15 at `192.168.1.121:8088`; this is acceptable/desired for isolation unless a DMZ pull-based secret operator is required.

Current blocker:

- kube-bot SSH login to IT15 is not working yet, so IT15-local preflight cannot be completed by kube-bot.

## IT15 Preflight Findings — 2026-06-13 05:53 UTC

Read-only checks over SSH succeeded using:

- `Misla@192.168.1.121`
- SSH key: default `~/.ssh/id_ed25519`

Findings:

- Host: IT15, Windows 10 Pro.
- RAM: ~32 GiB physical; WSL currently sees ~15 GiB.
- Disk C: ~1.24 TB free.
- WSL distros:
  - `Ubuntu` running, WSL2.
  - `docker-desktop` stopped.
- Ubuntu in WSL:
  - Ubuntu 26.04 LTS.
  - systemd is running.
  - root filesystem ~1007G, ~948G free.
  - `k3s` and `kubectl` not currently installed.
- Infisical containers running in Ubuntu/WSL:
  - `infisical-app` up.
  - `infisical-db` up/healthy.
  - `infisical-redis` up.
- Relevant ports in WSL:
  - `0.0.0.0:8088` socat.
  - `127.0.0.1:18080` docker-proxy to Infisical app.
- Infisical status locally: `Ok`.
- IT15/Windows and IT15/WSL can reach DMZ K3s API at `192.168.20.40:6443`.

Assessment:

- IT15 is suitable for a small single-node K3s management cluster from resource/network perspective.
- Next change step requires explicit OK: install K3s in Ubuntu/WSL and then install Argo CD.

## Implementation Status — 2026-06-13 06:00 UTC

Changes performed after explicit OK from Mislav:

- Installed K3s in IT15 WSL/Ubuntu as one-node management cluster.
  - Version: `v1.35.5+k3s1`
  - Node: `it15-mgmt`
  - Status: `Ready`
  - Disabled during install: Traefik, ServiceLB
- Installed Argo CD into namespace `argocd` on IT15 management K3s.
  - Install used official stable manifest.
  - One CRD required server-side apply due Kubernetes annotation size limit; corrected.
  - All Argo CD pods are `Running` and ready.
  - `argocd-server` is `ClusterIP` only.
  - No ingress exposed.
  - Initial admin secret exists, value was not printed.

Current status:

- IT15 management K3s: healthy.
- IT15 Argo CD: healthy.
- Existing DMZ Argo CD: unchanged.
- DMZ cluster is not yet connected to IT15 Argo CD.

Secret handling:

- No secret values were printed to Slack or logs intentionally.
- Infisical write path is currently blocked: no non-interactive Infisical API/CLI token was found in the runtime/IT15 environment.
- Argo CD initial admin password remains only in Kubernetes secret `argocd/argocd-initial-admin-secret` on IT15 management K3s until it can be stored/rotated via Infisical.

Next safe steps:

1. Read-only revalidate SSH access and kube contexts for IT15 management K3s and operative DMZ K3s.
2. Read-only identify the accidentally deployed dummy application on IT15 management K3s; do not delete/change without explicit OK.
3. Get/establish an Infisical write method without exposing credentials in chat/logs.
4. Run fresh Infisical backup + restore-test gate before storing operational secrets.
5. Store/rotate Argo CD initial admin credential in Infisical after explicit OK.
6. Add kube-bot/OpenClaw SSH private keys to Infisical as recovery-critical operational secrets after explicit OK; never print private key material.
7. Create restricted DMZ ServiceAccount/RBAC for pilot namespace after explicit OK.
8. Add operative DMZ cluster to IT15 Argo CD using the restricted credential.
9. Deploy the simple dummy application via IT15 Argo CD into the DMZ pilot namespace, not into IT15 management K3s.

## Ergänzung — OpenClaw/kube-bot SSH-Key Sicherung (2026-06-15 08:34 UTC)

Problem:
- OpenClaw-Updates können lokale SSH-Private-Keys verlieren.
- Dadurch wäre der Diagnose-/Admin-Zugriff auf IT15/DMZ ohne manuelle Wiederherstellung unterbrochen.

Ziel:
- kube-bot/OpenClaw SSH-Private-Keys als recovery-kritische Platform-Secrets in Infisical ablegen.
- Zugriff streng auf Platform/Admin-Kontext begrenzen.
- Keine Ausgabe von Private-Key-Material in Slack, Logs oder Dateien außerhalb des notwendigen sicheren Pfads.

Vorgehen nur nach explizitem OK:
1. Lokale SSH-Key-Pfade inventarisieren, ohne Inhalte auszugeben.
2. Zielpfad in Infisical festlegen, z.B. `/bots/kube-bot/ssh`. 
3. Infisical Backup/Restore-Gate prüfen.
4. Private Key + Public Key + Host-/Purpose-Metadaten über sicheren Write-Pfad speichern.
5. Restore/Readback nur als Fingerprint/Metadata validieren, nicht als Klartext-Ausgabe.