# Betriebskonzept — Plattform / K3s / DMZ / Intranet

Stand: 2026-06-11
Status: Entwurf v0.1
Owner künftig: platform-manager-bot
Aktuelle Pflege interimistisch: kube-bot mit Beiträgen von diskstation-bot und nextcloud-bot

## 1. Zweck

Dieses Betriebskonzept beschreibt, wie die Plattform täglich sicher betrieben wird.

Abgrenzung:
- Organisationskonzept: Rollen, Zuständigkeiten, Governance, Capabilities.
- Betriebskonzept: laufender Betrieb, Änderungen, Incidents, Backups, Monitoring, Security, Dokumentation.

## 2. Betriebsmodell

Die Plattform besteht aus:
- DMZ-K3s-Cluster für öffentlich erreichbare Workloads und Mandantenservices.
- Intranet-/Management-Zone für kritische Steuerungs- und Secret-Dienste, soweit verfügbar.
- Synology DiskStation als Übergangsort für Infisical-Pilot im Intranet.
- Reverse-Proxy-/Firewall-Kette: OPNsense -> Nginx Proxy Manager -> K3s/Traefik/Services.

Leitprinzipien:
- Sicherheit vor Geschwindigkeit.
- GitOps first.
- Keine Secrets in Git, Slack, Logs oder Bot-Memory.
- DMZ darf nicht frei ins Intranet sprechen.
- Änderungen nur mit explizitem OK des Owners.
- Bots arbeiten standardmäßig lesend/prüfend.

## 3. Rollen und Verantwortlichkeiten

### Mislav / Owner
- finale Entscheidungen
- Freigabe produktiver/riskanter Änderungen
- Priorisierung größerer Maßnahmen

### platform-manager-bot (geplant)
- Betriebskonzept, Service-Katalog, Entscheidungslog
- RACI, Roadmap, offene Aufgaben, Risiken
- Koordination der Fachbots
- keine direkten Adminrechte standardmäßig

### kube-bot
- K3s, Argo CD, Namespaces, Mandantentrennung
- Ingress/Traefik, NetworkPolicies, Cluster-Health
- GitOps-Struktur und Plattform-Runtime

### diskstation-bot
- Synology, Backups, Restore-Tests
- Backup-Ziele, Retention, NAS-Härtung
- Infisical-Pilot auf Synology aus NAS-Sicht

### nextcloud-bot
- Nextcloud-Anwendungsbetrieb Cattaro
- Updates, App-Konfiguration, Berechtigungen
- Backup-/Restore-Schnittstelle zur Plattform

### spätere Rollen
- secrets-bot: Infisical, Machine Identities, Rotation, Audit
- security-bot: DMZ/Exposure, Firewall-/Rechteprüfung, Security Reviews
- sre-bot: Monitoring, Alerting, SLOs, Incidents, Kapazität

## 4. Service-Katalog — erste Version

### Plattformservices
- Kubernetes Runtime / K3s
- GitOps / Argo CD
- Ingress / Traefik / Nginx Proxy Manager
- Secrets Management / Infisical
- Storage / Longhorn / local-path
- Backup / Restore / Synology
- Observability / Monitoring / Logging (noch auszubauen)
- Security / Exposure / Network Policies

### DevSecOps Self-Service
- Namespace/AppProject beantragen
- Infisical-Projekt oder Secret-Pfad beantragen
- Ingress/DNS beantragen
- Storage/PVC beantragen
- Backup/Restore-Anforderung stellen
- Anwendung in GitOps aufnehmen
- produktiven Change beantragen

## 5. Change Management / Change Enablement

### Standard Change
Niedriges Risiko, wiederholbar, dokumentiert.
Beispiele:
- read-only Statusprüfung
- Dokumentation aktualisieren
- nicht-produktive Inventur

### Normal Change
Produktive oder potentiell riskante Änderung mit Review.
Beispiele:
- Argo-CD-AppProject ändern
- Namespace-Struktur ändern
- Infisical-Secret-Sync einführen
- Ingress/DNS ändern
- Longhorn Settings ändern

### Emergency Change
Akute Störung/Sicherheitsrisiko.
Muss dokumentiert und nachträglich reviewed werden.

Regel:
Produktive, destruktive oder sicherheitsrelevante Änderungen brauchen explizites OK.

## 6. Incident Management

Ablauf:
1. Erkennen / Melden
2. Impact einschätzen: Plattform, Mandant, Anwendung, Backup, Security
3. Zuständigen Bot/Fachbereich einbinden
4. Read-only Diagnose zuerst
5. Maßnahme nur mit OK, außer ausdrücklich vorab freigegebene Standardreaktion
6. Ergebnis dokumentieren
7. Bei relevanten Incidents: kurzer Review

## 7. Problem Management

Wiederkehrende oder strukturelle Probleme werden als Problem geführt.
Aktuelle Kandidaten:
- Longhorn dauerhaft degraded wegen 3 Replicas bei 2 Nodes
- fehlendes Longhorn Backup Target
- uneinheitliche K3s-Versionen
- unklare Argo-CD-AppProject-/Mandantentrennung
- DMZ-Exposure administrativer Dienste

## 8. Backup & Restore Betrieb

Grundregeln:
- Backup ohne Restore-Test gilt nicht als verifiziert.
- Kritische Plattformdienste brauchen dokumentierte Restore-Prozedur.
- Backups bevorzugt außerhalb der DMZ.
- Infisical vor produktiver Nutzung: Backup und Restore testen.

Verantwortung:
- diskstation-bot fachlich
- kube-bot für Kubernetes-/Longhorn-Schnittstellen
- platform-manager-bot später für Nachhaltung

## 9. Security Operations

Regelmäßige Prüfpunkte:
- öffentliche Exposition von Argo CD, Portainer, Dashboard, Infisical
- DMZ -> Intranet Firewall-Regeln
- NetworkPolicies pro platform-* und tenant-* Namespace
- Secret-Rotation
- Bot-/ServiceAccount-Rechte
- Patch-/Update-Stand der Nodes
- GitOps-Repos und Tokens

## 10. Observability

Noch auszubauen.
Minimalziel:
- Cluster-Health
- Node-Ressourcen
- Pod-Restarts
- Storage/Longhorn Health
- Backup-Status
- Ingress/HTTP-Erreichbarkeit
- Zertifikatsstatus
- kritische App-Healthchecks

## 11. GitOps / Deployment-Betrieb

Ziel:
- Argo CD AppProjects pro Platform/Tenant
- keine Nutzung des Default-Projekts für Mandantenproduktion
- Repos und Ziel-Namespaces begrenzen
- produktive Sync-Regeln definieren
- Rollback-Pfad dokumentieren

## 12. Mandantenbetrieb

Grundsatz:
- ein Mandant = eigene Namespaces, eigenes AppProject, eigene Infisical-Struktur, eigene Identities.
- keine mandantenübergreifenden Runtime-Tokens.
- externe Unternehmen werden wie eigenständige Mandanten behandelt.

## 13. Dokumentation / Knowledge Management

Zu pflegen:
- Architekturentscheidungen
- Betriebskonzept
- Organisationskonzept
- Service-Katalog
- Runbooks
- Entscheidungslog
- Risikolog
- offene Aufgaben

## 14. Erste priorisierte Plattformaufgaben

P0 — Sicherheits-/Betriebsgrundlagen:
1. DMZ-Exposure administrativer Dienste prüfen: Argo CD, Portainer, Dashboard, später Infisical.
2. Longhorn Backup Target / Backup-Strategie klären.
3. Infisical-Pilot auf Synology planen inkl. Restore-Test.
4. K3s-Versionen und Upgrade-Pfad bewerten.

P1 — Struktur/GitOps:
5. Argo-CD-AppProjects für Platform/Tenant entwerfen.
6. Namespace-Zielstruktur vorbereiten.
7. GitOps-Repo-Struktur ableiten.
8. DevSecOps-Request-Templates definieren.

P2 — Härtung/Skalierung:
9. NetworkPolicy-Baseline entwerfen.
10. Longhorn Replica-Konzept festlegen.
11. Dritten Node / Intranet-Management-Node planen.
12. Monitoring-/Alerting-Mindeststandard definieren.

## 15. Kube-bot Arbeitsdokument

Kube-bot führt seine Plattformspur in:
- /home/node/.openclaw/workspace/PLATFORM_AUFGABEN_KUBE_BOT.md

Inhalt:
- DMZ-Exposure
- Argo-CD-/GitOps-Zielstruktur
- K3s-/Longhorn-Risiken
- DevSecOps-Request-Templates

## Entscheidung — Mandantenname Pidoka

Für den heckenfels.com/Pidoka-Bereich wird `pidoka` als Mandantenname standardisiert.

Namensschema:
- `tenant-pidoka-stage`
- `tenant-pidoka-prod`
- Argo-CD-AppProject `tenant-pidoka`
- Infisical-Projekt `tenant-pidoka`