# Konzeptnotiz — Argo CD + K3s + Infisical Stand: 2026-06-11 Owner-Kontext: Mislav / K3s-Umgebung / Cattaro GmbH und externe Mandanten ## Zielbild Mandanten-Workloads Argo CD steuert Deployments deklarativ aus Git. Infisical verwaltet Secrets zentral. K3s führt Workloads aus. Mandanten wie Cattaro GmbH und externe Unternehmen werden technisch getrennt: - eigener Kubernetes-Namespace oder Namespace-Set pro Mandant - eigenes Argo-CD-AppProject pro Mandant - eigenes Infisical-Projekt oder streng getrennte Infisical-Struktur pro Mandant - eigene ServiceAccounts/RBAC-Regeln - eigene Machine Identity / Secret-Sync-Identity pro Mandant oder Workload - keine globalen Tokens in Mandanten-Workloads - keine Klartext-Secrets in Git, Slack, Logs, Collectives oder Bot-Memory Empfohlene Regel: ein Mandant = ein Argo-CD-AppProject + ein Namespace-Set + ein Infisical-Projekt + eigene Sync-Identity. ## Infrastrukturdienste / mandantenübergreifende Plattform Bestimmte Dienste wie Infisical, Argo CD, Ingress, Monitoring, Logging, Backup, Zertifikatsmanagement oder ggf. Registry/Storage werden mandantenübergreifend bereitgestellt. Diese Dienste gehören nicht in einen Kunden-/Mandanten-Namespace, sondern in eine eigene Plattform-/Infrastruktur-Schicht mit separatem Betriebsmodell. Grundsatz: Plattformdienste dürfen Mandanten bedienen, aber Mandanten dürfen Plattformdienste nicht administrieren. # Konkrete Zielstruktur — Vorschlag ## Namespace-Struktur ### Platform / mandantenübergreifend - platform-argocd - platform-secrets - platform-ingress - platform-cert-manager - platform-monitoring - platform-logging - platform-backup - platform-storage ### Mandanten - tenant-cattaro-prod - tenant-cattaro-stage - tenant-kunde-a-prod - tenant-kunde-a-stage Alternative bei kleineren Mandanten: ein Namespace pro Mandant plus Environment über Labels/Apps trennen. Für echte externe Kunden ist Namespace pro Mandant und Environment sauberer. ## Argo CD AppProjects - platform-core - platform-observability - platform-security - tenant-cattaro - tenant-kunde-a Regeln: - platform-* Projekte dürfen platform-* Namespaces verwalten. - tenant-* Projekte dürfen nur eigene tenant-* Namespaces verwalten. - Cluster-scoped Ressourcen nur in Platform-Projekten erlauben. - Mandanten-Projekte bekommen keine Rechte auf CRDs, ClusterRoles, ClusterRoleBindings oder andere Mandanten-Namespaces. ## Infisical Struktur ### Infisical als Plattformdienst - Betrieb im Namespace: platform-secrets - Admin-Zugriff nur Platform-Admins - Backup/Restore verpflichtend - MFA und Audit-Logs aktiv ### Infisical Projekte - platform-infra - tenant-cattaro - tenant-kunde-a ### Environments - dev - stage - prod ### Secret-Pfade - /kithub/api - /kithub/database - /bots/kube-bot - /integrations/github - /integrations/docker - /integrations/nextcloud ## Kubernetes Secret-Sync - pro Mandant eigene Infisical Machine Identity - pro Namespace eigener SecretStore/Auth-Mechanismus - pro Workload eigene ExternalSecret/InfisicalSecret Definition - keine globalen Runtime-Tokens - Rotation über Infisical, Reconcile über Operator ## Verantwortlichkeiten ### Platform Admin - Argo CD Betrieb - Infisical Betrieb - Ingress/Cert/Monitoring/Backup - Cluster-weite Ressourcen ### Mandanten Operator - Deployments im eigenen Mandantenbereich - Zugriff auf eigene Argo-CD-Apps - Zugriff auf eigene Infisical-Projekte ### Workload Identity - minimaler Secret-Lesezugriff - keine Admin-Rechte - kein Zugriff auf andere Mandanten oder Platform-Secrets ## Labels / Standards Empfohlene Labels: - owner: platform|cattaro|kunde-a - tenant: cattaro|kunde-a|platform - environment: dev|stage|prod - managed-by: argocd - data-classification: internal|confidential|secret ## Rollout-Reihenfolge konkret 1. Namespace- und AppProject-Namensschema bestätigen. 2. Platform-AppProjects definieren. 3. Tenant-AppProject für Cattaro definieren. 4. Infisical Projekt tenant-cattaro anlegen. 5. Machine Identity für einen Pilot-Workload erstellen. 6. Einen unkritischen Secret-Sync testen. 7. Kit Hub in tenant-cattaro-stage migrieren. 8. Rotation und Rollback testen. 9. Kit Hub prod migrieren. 10. Erst danach externe Mandanten modellieren. # Aufgaben / Merkpunkte — Zielarchitektur und DMZ-Bewertung ## Gespeicherte Zielarchitektur Die Konzepte werden getrennt geführt: 1. Mandanten-Konzept - Workloads, Secrets, Argo-CD-Apps und Namespaces pro Mandant getrennt. - Externe Unternehmen werden wie eigenständige Mandanten behandelt. 2. Platform-Konzept - Mandantenübergreifende Infrastruktur wie Argo CD, Infisical, Ingress, cert-manager, Monitoring, Logging, Backup, Storage. - Platform darf Mandanten bedienen, Mandanten dürfen Platform nicht administrieren. ## Aktuelle Node-/DMZ-Bewertung — Stand Inventur 2026-06-08 Nodes: - 192.168.20.40 mbrkanov-mini-it13: control-plane/master, Ubuntu 22.04.5, K3s v1.28.4+k3s2, 32GB RAM, 1.4TB NVMe - 192.168.20.45 mini-it13-02: worker, Ubuntu 22.04.5, K3s v1.29.3+k3s1, 32GB RAM, 768GB NVMe Auffälligkeiten: - Nur 2 K3s Nodes: keine echte HA-/Quorum-Reserve für kritische Plattformdienste. - K3s-Versionen sind uneinheitlich. - Longhorn ist mit 3 Replicas konfiguriert, aber nur 2 Nodes vorhanden; Volumes dauerhaft degraded. - Longhorn Backup Target war leer/nicht verfügbar. - Cluster liegt in DMZ; administrative Dienste und Secret-Management brauchen besonders restriktive Exposition. ## Sicherheitsleitlinien für DMZ - Infisical nicht öffentlich verfügbar machen, außer zwingend notwendig und dann nur mit starker Auth/MFA, IP-/VPN-Beschränkung und WAF/Proxy-Härtung. - Argo CD Adminzugriff nicht öffentlich breit exponieren; bevorzugt VPN/ZTNA/Management-Netz. - Keine globalen Tokens in Pods. - Keine mandantenübergreifenden Machine Identities. - NetworkPolicies als Pflicht für tenant-* und platform-* Namespaces einplanen. - Egress von Workloads restriktiv betrachten. - Backups außerhalb der DMZ ablegen und Restore testen. ## Infrastruktur-Verteilung — Ziel Kurzfristig bei 2 Nodes: - Argo CD redundant soweit möglich verteilen, aber bewusst: control-plane bleibt Single-Risk. - Infisical nur nach Backup/Restore-Konzept und möglichst mit externer/Longhorn-gesicherter Datenbank. - Platform-Komponenten mit PodAntiAffinity auf beide Nodes verteilen. - Ingress/Traefik auf beiden Nodes betreiben, Exposition über Proxy/Firewall kontrollieren. Mittelfristig empfohlen: - Dritten K3s Node ergänzen, idealerweise als weiterer worker oder server je nach gewünschtem HA-Modell. - Für kritische Platform-Dienste nodeAffinity/tolerations/taints sauber definieren. - Optional Management-/Platform-Node oder separates Management-Netz prüfen, um Secrets/Admin-UIs nicht rein öffentlich in der DMZ zu betreiben. ## Vorbereitende Aufgaben vor Infisical-Produktivbetrieb 1. Backup-Ziel für Longhorn/Infisical klären. 2. Restore-Test definieren. 3. K3s-Versionen harmonisieren. 4. Longhorn Replica-Konzept für 2 oder 3 Nodes festlegen. 5. DMZ-Exposure für Argo CD, Infisical, Dashboard, Portainer prüfen. 6. NetworkPolicy-Baseline einführen. 7. AppProjects/RBAC/Mandantengrenzen in Argo CD vorbereiten. 8. Infisical-Projekte und Machine Identities mandantenscharf modellieren. # Architekturergänzung — Kritische Platform-Dienste außerhalb der DMZ ## Grundsatz Kritische mandantenübergreifende Infrastruktur sollte möglichst nicht in der DMZ betrieben werden, wenn sie administrative Kontrolle, Secrets oder zentrale Betriebsfunktionen bereitstellt. Bevorzugtes Modell: - DMZ betreibt öffentlich erreichbare Workloads / Edge-Komponenten. - Intranet betreibt zentrale Steuerungs- und Secret-Infrastruktur. - Verkehrsrichtung: Intranet -> DMZ erlaubt und kontrolliert. - Verkehrsrichtung: DMZ -> Intranet grundsätzlich blockiert oder nur extrem eng freigegeben. ## Dienste, die bevorzugt ins Intranet gehören - Infisical - Argo CD Control Plane - zentrale CI/CD Runner, falls administrativ mächtig - Monitoring/Logging-Zentrale mit sensitiven Logs - Backup-/Restore-Steuerung - Admin-Dashboards - ggf. Container Registry, wenn sie private Images und Credentials hält ## Dienste, die in der DMZ bleiben können/müssen - Ingress Controller / Gateway / Reverse Proxy Edge - öffentlich erreichbare Mandanten-Workloads - ggf. lokale Agents/Controller, die von Intranet-Systemen gesteuert werden - minimale Sync-Komponenten mit streng begrenzten Credentials ## Infisical-Variante Best Practice in dieser Umgebung: - Infisical läuft im Intranet. - DMZ-Workloads erhalten keine breit berechtigten Infisical-Zugriffe. - Secret-Sync in die DMZ erfolgt über eng begrenzte Pull-Identities oder über kontrollierten Push aus dem Intranet. - Machine Identities sind mandanten- und workload-scharf. - Firewall-Regeln erlauben nur notwendige Ports/Ziele. ## Argo-CD-Variante Bevorzugt: - Argo CD Server/UI/Controller laufen im Intranet oder Management-Cluster. - Argo CD steuert den DMZ-K3s-Cluster über Kubernetes API mit eingeschränktem ServiceAccount/RBAC. - Die Kubernetes API der DMZ ist nicht öffentlich, sondern nur aus dem Intranet/Management-Netz erreichbar. Alternative: - Argo CD bleibt in der DMZ, aber UI/API nur via VPN/ZTNA/IP-Allowlist. - Diese Variante ist weniger sauber als Intranet/Management-Zone. ## Sicherheitsziel Eine kompromittierte DMZ-App darf nicht automatisch Zugriff auf zentrale Secrets, Backups, Argo CD Adminfunktionen oder Intranet-Systeme erhalten. ## Ergänzung NAS-/Backup-Sicht: Sync-Richtung Infisical / DMZ Wichtiger Architekturpunkt: Viele Secret-Operator-Modelle arbeiten als Pull aus dem Cluster. Wenn der Operator in der DMZ läuft und Infisical im Intranet steht, entsteht technisch DMZ -> Intranet Traffic. Das darf nicht unbewusst oder breit erlaubt werden. Bevorzugte Variante: - Steuerung/Synchronisation aus dem Intranet Richtung DMZ. - Intranet/Management-Zone hält zentrale Kontrolle, Secrets, Backups und Admin-UIs. - DMZ nimmt nur eng definierte Änderungen/Secrets entgegen. Fallback-Variante, falls DMZ -> Infisical technisch nötig ist: - ausschließlich HTTPS zur konkreten Infisical-Adresse - Firewall-Regel eng auf Quell-Namespace/Node/Service und Ziel/Port begrenzen, soweit technisch möglich - pro Mandant/Workload eigene Machine Identity - nur Leserechte auf benötigte Secret-Pfade - Audit-Logs aktiv auswerten - keine globalen Tokens - kein Zugriff aus DMZ auf DiskStation, Backup-Ziele, Admin-UIs oder andere Intranet-Systeme Sicherheitsziel: Eine kompromittierte DMZ-App darf weder DiskStation/Backups/Admin-UIs erreichen noch zentrale Secret- oder Deployment-Kontrolle übernehmen. ## Ergänzung Backup-Zielbild: dmz-backup als Staging-Hop Stand 2026-06-19: Es gibt einen dedizierten Hilfs-Backup-Server in der DMZ: - Name: `dmz-backup` - IP: `192.168.20.90` - Rolle: DMZ-Staging-Ziel fuer Cluster-Backups Neues Zielbild: - K3s/DMZ-Cluster pusht Backup-Dateien nur nach `dmz-backup`. - Synology/DiskStation pullt von `dmz-backup` und bleibt Backup-Master. - Direkte Schreibrechte aus der DMZ auf Synology werden vermieden. - `dmz-backup` ist Puffer/Staging-Zone, nicht langfristige alleinige Backup-Quelle. Ordnung der Backup-Pfade: - Top-Level nach `platform`, `tenants` und `legacy`. - Darunter nach Umgebung (`prod`, `stage`, `dev`), Anwendung und Backup-Art. - Kubernetes-Namespaces werden als Metadaten dokumentiert, aber nicht als einzige Ordnungsstruktur verwendet, weil einige Namespaces historisch gewachsen sind. Vorgeschlagener Staging-Root: ```text /srv/dmz-backup/k3s-dmz/ ``` Vorgeschlagenes Schema: ```text k3s-dmz/ platform/ argocd/prod/ infisical/prod/ external-secrets/prod/ longhorn/prod/ nginx-proxy-manager/prod/ cluster/prod/ tenants/ pidoka/prod// cattaro/stage// cattaro/prod// legacy/ /prod/ ``` Detailentwurf fuer diskstation-bot: - `/home/node/.openclaw/workspace/inventory/backup-folder-structure-dmz-backup-20260619.md` Sicherheitsregeln: - Cluster bekommt nur Schreibrechte auf definierte Zielpfade auf `dmz-backup`. - Synology bekommt Pull-Rechte von `dmz-backup`, idealerweise read-only. - Kein breit nutzbarer Synology-Key im Cluster. - Backups mit Secret-/Credential-Inhalt markieren und bevorzugt vor Ablage verschluesseln. - Synology-Pull initial ohne destruktives `--delete`. - Backup gilt erst nach Restore-Test als belastbar. # Umsetzungsvariante bei fehlendem Intranet-Node Stand: Es gibt aktuell keinen freien Intranet-Node für Infisical/Argo-CD-Management-Zone. Option A: Übergangsweise Synology DiskStation Docker nutzen - Sicherheitsseitig besser als Betrieb in der DMZ, weil zentrale Secret-/Steuerungsdienste im Intranet bleiben. - Nur sinnvoll, wenn DiskStation-Ressourcen, Backup, Docker-Betrieb, Updates und Zugriffshärtung ausreichend sind. - Risiko: DiskStation wird stärker zur kritischen Plattform-Komponente; NAS-/Backup-Funktion und Secret-/Management-Funktion koppeln sich. - Voraussetzung: keine öffentliche Exposition, MFA/starke Admin-Härtung, getrennte Docker-Volumes, regelmäßiges Backup und getesteter Restore. Option B: Vorerst Betrieb in DMZ - Funktional einfacher, aber sicherheitlich schwächer. - Nur als Übergang mit harten Einschränkungen: kein öffentlicher Adminzugriff, VPN/ZTNA/IP-Allowlist, Backups außerhalb DMZ, minimale Tokens, NetworkPolicies. Empfehlung: - Wenn DiskStation-Bot/NAS-Sicht keine harten Einwände hat, Infisical bevorzugt übergangsweise im Intranet auf der DiskStation betreiben. - Argo CD kann zunächst in der DMZ bleiben, aber Adminzugriff absichern; langfristig ebenfalls Management-Zone/Intranet. - Wenn DiskStation ungeeignet ist, DMZ-Variante nur als bewusst temporärer Zustand mit dokumentiertem Risiko. # Entscheidungsvorschlag nach DiskStation-Bewertung DiskStation-Bewertung: - Modell: DS918+ - RAM: 4 GB - DSM: 7.3.2-86009 Update 3 - Container Manager: 24.0.2-1606 - Einschätzung: geeignet als Übergang/Pilot für Infisical, nicht als dauerhafte Plattform-Zentrale. Festlegung für Zielarchitektur: - Infisical darf übergangsweise auf der Synology DiskStation im Intranet betrieben werden. - Kein öffentlicher Zugriff auf Infisical. - Zugriff nur aus Intranet/VPN/ZTNA. - Docker-Volumes getrennt sichern. - Restore-Test vor produktiver Secret-Migration. - Keine Bündelung zusätzlicher schwerer Plattformdienste wie Argo CD, Monitoring oder Logging auf der DiskStation. - Langfristig dedizierten Intranet-/Management-Node für Platform-Dienste planen. Bewertung: Diese Übergangslösung ist sicherheitlich besser als Infisical in der DMZ, koppelt aber Secret-Management und NAS/Backup enger. Deshalb nur als Pilot/Übergang nutzen und bewusst klein halten. # Organisationskonzept — KI-Assistenten für Plattform, Infrastruktur und DevSecOps-Nutzung ## Grundsatz Die Infrastruktur wird wie eine Plattform betrieben: zentrale Platform-/Infra-Teams stellen sichere Self-Service-Bausteine bereit; DevSecOps-/Anwendungsteams konsumieren diese über definierte Schnittstellen. Bots/Assistenten bekommen klare Verantwortungsbereiche, minimale Rechte und arbeiten nach Vier-Augen-/Approval-Prinzip für Änderungen. ## Rollenmodell ### Platform Governance / Architektur - Verantwortet Zielarchitektur, Standards, Mandantentrennung, Namenskonventionen, Sicherheitsleitlinien. - Entscheidet nicht allein produktive Änderungen, sondern bereitet Entscheidungsgrundlagen vor. ### Kubernetes Platform Bot (kube-bot) - K3s, Namespaces, Argo CD, AppProjects, RBAC, Ingress/Traefik, NetworkPolicies, Cluster-Health. - Erst read-only; Änderungen nur nach explizitem OK. ### Storage/Backup/NAS Bot (diskstation-bot) - Synology, Backups, Restore-Tests, Backup-Ziele, NAS-Sicherheit, Container Manager auf Synology. - Fokus auf Datenresilienz und Restore-Fähigkeit. ### Secrets/IAM Bot (vorgeschlagen) - Infisical, Secret-Rotation, Machine Identities, Zugriffspfade, Audit, MFA, Key-Lifecycle. - Könnte langfristig eigener Bot werden oder zunächst zwischen kube-bot und diskstation-bot geteilt. ### Observability/SRE Bot (vorgeschlagen) - Monitoring, Logging, Alerting, SLOs, Dashboards, Incident-Zusammenfassungen. - Sollte nicht gleichzeitig für produktive Änderungen zuständig sein. ### Security/Compliance Bot (vorgeschlagen) - Risikoanalysen, DMZ-Regeln, Exposure-Prüfungen, NetworkPolicies, Patch-/Vulnerability-Bewertung, Audit-Checks. - Empfehlend/prüfend, nicht primär ausführend. ### Application Bots - Beispiel nextcloud-bot für Nextcloud Cattaro. - Verantwortet Anwendungsebene, nutzt Plattformdienste über definierte Requests/Schnittstellen. - Keine direkten Cluster-/Platform-Adminrechte. ## DevSecOps-Team-Zugriff DevSecOps-Teams sollen Plattformdienste nicht direkt administrieren, sondern über Self-Service und kontrollierte Schnittstellen nutzen: - GitOps-Repositories / Pull Requests - Argo-CD-AppProjects pro Mandant/Team - Namespace-Templates - Infisical-Projekte/Environments pro Mandant/App - ServiceAccounts mit minimalem Scope - dokumentierte Request-Flows für DNS/Ingress/Secrets/Storage/Backups - produktive Änderungen über Approval/Review ## Empfohlene Prozesse - Service-Onboarding-Request - Secret-Onboarding-Request - Ingress/DNS-Request - Backup/Restore-Anforderung - Incident-/Change-Prozess - regelmäßige Plattform-Reviews ## Leitprinzipien - Least Privilege - Separation of Duties - GitOps first - No Secrets in Chat/Git/Logs - DMZ und Intranet strikt trennen - Bots handeln nicht autonom destruktiv - Änderungen nur mit explizitem OK von Mislav oder definiertem Owner ## Konsens diskstation-bot / kube-bot zur KI-Organisation Bestätigter Schnitt: - kube-bot: Plattform-Runtime — K3s, Argo CD, Namespaces, Mandantentrennung, Ingress, NetworkPolicies - diskstation-bot: Daten-/Backup-Sicherung — Synology, Backup-Ziele, Restore-Tests, Retention, NAS-Härtung - nextcloud-bot: Anwendungsebene Nextcloud/Cattaro — nutzt Plattformdienste, verwaltet sie nicht Zusätzliche Rollen mit Bedarf: - secrets-bot: Infisical, Machine Identities, Rotation, Audit - security-bot: DMZ-Exposure, Firewall-/Netzkonzept, Rechteprüfung - sre-bot: Monitoring, Alerting, Kapazität, Incidents Grundregel: Kein Bot darf alles. Standard ist lesend/prüfend. Schreibaktionen nur im eigenen Verantwortungsbereich; produktive/destruktive Aktionen nur mit explizitem OK. DevSecOps-Teams erhalten Self-Service über GitOps/Requests statt direkten Infrastrukturzugriff: - AppProject - Namespace - Infisical-Projekt - Backup-Anforderung - Ingress/DNS-Anforderung - Review/Approval # Ergänzung — IT-Manager / Platform Governance Agent ## Einschätzung Eine koordinierende IT-Manager-/Platform-Governance-Rolle bleibt notwendig. Gerade bei mehreren spezialisierten KI-Assistenten verhindert diese Rolle, dass einzelne Bots isoliert optimieren, Zuständigkeiten verschwimmen oder Architekturentscheidungen nicht nachgehalten werden. ## Rolle: IT-Manager / Platform Governance Agent Aufgaben: - Zielorganisation und Rollenmodell definieren und pflegen - IT-Capabilities strukturieren, z. B. angelehnt an IT4IT/Open Group - Service-Katalog und Plattform-Services beschreiben - Verantwortlichkeiten/RACI je Service und Bot pflegen - Entscheidungsprotokolle, Architekturentscheidungen und offene Aufgaben nachhalten - Change-/Approval-Prozesse definieren - DevSecOps-Self-Service-Prozesse standardisieren - Roadmap, Prioritäten und Risiken konsolidieren - Reviews zwischen kube-bot, diskstation-bot, secrets-bot, security-bot, sre-bot und Application-Bots koordinieren Nicht-Aufgaben: - keine eigenständige technische Ausführung ohne Owner-OK - keine Alleinentscheidung über produktive Änderungen - kein globaler Zugriff auf Secrets oder Systeme ## Organisatorische Orientierung Empfohlenes Modell: - Agile Arbeitsweise für Umsetzung und kontinuierliche Verbesserung - IT4IT-/Capability-Denken für Struktur, Services und Verantwortlichkeiten - ITIL-Ideen selektiv übernehmen, insbesondere: - Incident Management - Change Enablement - Service Request Management - Problem Management - Configuration/Asset Management - Service Catalog Management - Knowledge Management ## Vorgeschlagene Capabilities - Platform Runtime Management - Secret & Identity Management - Backup & Restore Management - Observability & Incident Management - Security & Exposure Management - Application Service Management - Service Request & Change Management - Architecture & Governance Management ## Bot-Vorschlag Neuer Agent: it-manager-bot oder platform-manager-bot Primäre Funktion: - koordinieren, strukturieren, dokumentieren, nachhalten - Arbeitspakete und Verantwortlichkeiten zwischen Bots/Teams schneiden - Standards/Templates pflegen - Entscheidungsbedarf an Mislav eskalieren Rechteprofil: - lesender Zugriff auf Konzepte, Inventare, Statusberichte und Tickets/Requests - Schreibzugriff auf Dokumentation, Roadmap, Service-Katalog, Entscheidungslog - keine direkten Admin-/Secret-/Cluster-Rechte standardmäßig # Betriebskonzept — noch separat auszuarbeiten Status: Es existieren bereits Bausteine für ein Betriebskonzept: - Zielarchitektur DMZ/Intranet - Mandantenmodell - Platform-/Tenant-Trennung - Bot-Rollenmodell - Backup-/Restore-Leitlinien - Security-/DMZ-Leitlinien - DevSecOps-Self-Service-Idee Es fehlt aber noch ein eigenständiges Betriebskonzept, das den laufenden Betrieb verbindlich beschreibt. ## Inhalte des Betriebskonzepts 1. Betriebsmodell - Betriebszeiten / erwartete Reaktionszeiten - Zuständigkeiten je Service - Eskalationswege - Bot-/Owner-Rollen 2. Service-Katalog - Plattformservices - Mandantenservices - Self-Service-Angebote für DevSecOps-Teams - Service Owner je Service 3. Change Management / Change Enablement - Standard Changes - Normal Changes - Emergency Changes - Approval-Regeln - Rollback-Pflicht 4. Incident Management - Erkennung - Einstufung - Erstreaktion - Kommunikation - Post-Incident-Review 5. Problem Management - wiederkehrende Fehler - Root-Cause-Analysen - technische Schulden 6. Backup & Restore Betrieb - Backup-Frequenzen - Retention - Restore-Tests - Verantwortlichkeiten 7. Security Operations - Patch-/Update-Rhythmus - Exposure-Checks - Secret-Rotation - Audit-Review - DMZ/Intranet-Firewall-Regeln 8. Observability - Monitoring - Logging - Alerting - SLOs/SLIs - Kapazitätsplanung 9. GitOps/Deployment-Betrieb - Repo-Struktur - PR-/Review-Regeln - Argo-CD-Sync-Regeln - Rollback-Prozess 10. Dokumentation / Knowledge Management - Architekturentscheidungen - Runbooks - Service-Dokumentation - Entscheidungslog Empfehlung: Das Betriebskonzept sollte als separates Dokument entstehen und vom platform-manager-bot gepflegt werden. Fachbots liefern ihre Kapitel zu. ## Konsens zum Betriebskonzept Konsens kube-bot / diskstation-bot / nextcloud-bot: - Organisationskonzept und Betriebskonzept werden getrennt. - Organisationskonzept = Wer macht was, Rollen, Verantwortlichkeiten, Governance, Capabilities. - Betriebskonzept = Wie wird die Plattform im Alltag sicher betrieben. Fachbeiträge: - platform-manager-bot: Owner/Pflege des Betriebskonzepts, Struktur, Entscheidungslog, RACI, Service-Katalog - kube-bot: K3s, Argo CD, GitOps, Namespaces, Mandantentrennung, Ingress, NetworkPolicies - diskstation-bot: Backup-/Restore-Betrieb, NAS/Synology, Retention, Restore-Tests - nextcloud-bot: Anwendungsteil Nextcloud, Updates, Backup-Schnittstelle, Berechtigungen, Service Requests - später secrets-bot: Infisical, Rotation, Machine Identities, Audit - später security-bot: Exposure, DMZ/Intranet, Firewall-/Rechteprüfung - später sre-bot: Monitoring, Alerting, Incidents, Kapazität Das Betriebskonzept soll leichtgewichtig, aber explizit sein. # Verweis Betriebskonzept Ein separates Betriebskonzept wurde als Entwurf angelegt: - /home/node/.openclaw/workspace/BETRIEBSKONZEPT_PLATFORM.md Status: v0.1, interimistisch durch kube-bot gepflegt, später Owner platform-manager-bot. # Aktualisierung — 2026-06-14 — Organisationsgrenze Infisical Entscheidung: - Für Cattaro-Infrastruktur und Cattaro-Fachanwendungen wird in Infisical die Organisation `cattaro_gmbh` verwendet. - Die Organisation `Admin Org` ist nicht die fachliche Zielgrenze für Cattaro-Betrieb und soll nicht als Default für Cattaro-Identities dienen. Angepasstes Zielmodell: ## Infisical - Organisation `cattaro_gmbh` - Projekt `platform-infra` oder vorhandenes Cattaro-Platform-Projekt für Argo CD, kube-bot, Registry-, Git- und Infrastruktur-Integrationen. - Projekt `tenant-cattaro` für Cattaro-Fachanwendungen. - Environments: `dev`, `stage`, `prod`. - Machine Identities mandantenscharf und möglichst workload-scharf: - `mi-platform-argocd-read` / `mi-platform-argocd-sync` - `mi-tenant-cattaro--stage` - `mi-tenant-cattaro--prod` - Keine Identity darf mandantenübergreifend Secrets lesen. - Für externe Mandanten später jeweils eigene fachliche Grenze: - bevorzugt eigenes Infisical-Projekt `tenant-` innerhalb einer passend verwalteten Organisation, falls Cattaro den Betrieb zentral verantwortet; - alternativ eigene Infisical-Organisation je externem Mandanten, wenn rechtliche/operative Trennung, Audit oder Admin-Delegation das erfordern. ## Argo CD - Platform-AppProjects: - `platform-core` - `platform-security` - `platform-observability` - Cattaro-Fachanwendungen: - AppProject `tenant-cattaro` - erlaubt nur Namespaces `tenant-cattaro-dev`, `tenant-cattaro-stage`, `tenant-cattaro-prod` - Externe Mandanten: - je Mandant eigenes AppProject `tenant-` - keine Cluster-scoped Ressourcen - kein Zugriff auf andere Tenant-Namespaces ## Kubernetes - Platform Namespaces bleiben getrennt von Fachanwendungen: - `platform-argocd` - `platform-secrets` - `platform-ingress` - `platform-monitoring` - Cattaro-Fachanwendungen: - `tenant-cattaro-dev` - `tenant-cattaro-stage` - `tenant-cattaro-prod` - Externe Mandanten analog: - `tenant--stage` - `tenant--prod` Guardrails: - Kein Cattaro-Betrieb über `Admin Org`-Identities. - Kein globales Infisical-Token in Argo CD oder Workloads. - Secrets bleiben in Infisical; Git enthält nur Referenzen/ExternalSecret-Definitionen. - Produktiv-Identities strikt getrennt von Stage/Dev.