Traefik laeuft im Cluster in kube-system ohne Host-Netzwerk (geprueft).
Die App ist damit nur noch fuer Traefik-Pods aus kube-system erreichbar
(Namespace + Label), was die Umgehung der Login-/2FA-Rate-Limits per
gefaelschtem X-Real-Ip aus anderen Pods verhindert.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
- Dateinamen nach Wabenhain-Schema (01-configmap, 02-secret,
03-storage, 04-postgres, 05-app-deployment, 06-ingress,
07-worker-cronjob, 08-networkpolicy); Secret-Vorlage als
02-secret.yaml.example, echte 02-secret.yaml gitignored.
- Namespace: Pod Security "baseline" erzwungen, "restricted" als warn/audit.
"restricted" kann den HTTP-01-Solver-Pod von cert-manager abweisen und
damit die Zertifikatsausstellung blockieren.
- NetworkPolicy nur noch fuer PostgreSQL; keine Policy vor der App (wie
Wabenhain/ApiCore), da sie bei Traefik im Host-Netzwerk die Seite sperrt.
- README: kompletter Neuaufbau inkl. Freigabe der Retain-PVs nach
"kubectl delete namespace", Zertifikats-Diagnose.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Nur Label-Abgleich ueber alle Namespaces liess jeden Pod mit Label
app.kubernetes.io/name=traefik zu. Jetzt muss zusaetzlich der Namespace
traefik oder kube-system sein (Namespace-Namen sind nicht faelschbar).
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Voraussetzungen pruefen (Traefik, cert-manager, csi-driver-smb),
Einzel-Applies in Reihenfolge mit kubectl wait auf Postgres,
Fehlersuche fuer Migration, App und Zertifikat.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
- Ingress: HTTP->HTTPS-Middleware redirect-to-https wieder am Ingress
(wie Wabenhain), Service-Port als Nummer, cert-manager letsencrypt-prod.
- NetworkPolicy: Traefik ueber das Pod-Label (traefik/rke2-traefik) in
jedem Namespace erkannt statt fester Namespace "traefik" - verhindert,
dass die Seite unerreichbar wird, wenn Traefik z. B. in kube-system laeuft.
- README: Voraussetzungen pruefen und Deployment Schritt fuer Schritt
(kubectl wait auf Postgres) wie bei Wabenhain.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Der Migrations-initContainer scheiterte: "pnpm install --ignore-scripts"
ueberspringt das postinstall von @prisma/engines, das die Schema-Engine
fuer "prisma migrate deploy" herunterlaedt. Der Builder holt das jetzt mit
"pnpm rebuild @prisma/engines prisma" nach. Zusaetzlich openssl in der
Basisstufe, weil die Engine unter Alpine libssl braucht.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Befunde des Commit-Security-Reviews: automountServiceAccountToken: false
fuer Postgres, App und Worker; Speicherlimits fuer Migrations-initContainer
und Worker; Laufzeitgrenze (activeDeadlineSeconds) fuer den Worker;
Groessenlimits fuer die emptyDir-Volumes.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Auf Wunsch des Betreibers auf das Noetige reduziert: StatefulSet
PostgreSQL, Services, Ingress, App-Deployment, zwei SMB-PersistentVolumes
(Postgres-Daten, Medien). Beibehalten nach Absprache: Worker-CronJob
(Folgeraten, Reservierungsfreigabe, Mail-Wiederholung), ConfigMap und die
NetworkPolicies (Sicherheitsbefund Rate-Limit-Umgehung).
- Migration als initContainer im App-Deployment statt eigenem Job
- Entfernt: Backup-CronJob/-Volume (NAS sichert die Freigabe),
Migrations-CronJob, PodDisruptionBudget, HTTP-Redirect-Ingress und
Middleware, Namespace-Objekt (einmalig von Hand anzulegen)
- PostgreSQL auf SMB als bewusste, dokumentierte Ausnahme mit
hard, cache=strict, SMB 3.1.1 + seal, uid 70 / 0700
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Befunde des Commit-Security-Reviews behoben:
- Klartextuebertragung: vers=3.1.1 mit "seal" (SMB3-Verschluesselung)
fuer Medien- und Backup-Volume.
- Rueckschritt Zugriffskontrolle: Backup-PV/PVC wieder ReadWriteOnce statt
ReadWriteMany (nur der Backup-Job haengt es ein).
- Zu weite Rechte: Medien-Volume nur lesbar (dir_mode 0550, file_mode
0440); geschrieben wird ausschliesslich ueber das NAS.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Statische PVs ueber csi-driver-smb (smb.csi.k8s.io), fest an die PVCs
artista-modelcamp-media (App liest, uid 1001) und
artista-modelcamp-db-backup (pg_dump-Job, uid 70, 0700/0600) gebunden,
reclaimPolicy Retain. Zugang ueber Secret artista-modelcamp-smb.
Das PostgreSQL-Datenverzeichnis bleibt bewusst auf Blockspeicher
(SMB erfuellt dessen Sperr- und fsync-Anforderungen nicht, Briefing §13);
die Datenbank landet ueber die taeglichen Dumps trotzdem auf dem NAS.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Alle Ressourcen tragen den Praefix artista-modelcamp- im Namespace
artista; Images <owner>/artista-modelcamp und
<owner>/artista-modelcamp-tools. DATABASE_URL-Host, Backup-Host,
Traefik-Middleware-Referenz und Betriebsdoku entsprechend angepasst.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Alle Ressourcen tragen den Praefix artista-filmcamp- (Deployment,
Service, StatefulSet, CronJobs, PVCs, ConfigMap, Secret, Ingress,
NetworkPolicies, Middleware) und liegen im Namespace artista. Die Images
heissen wieder <owner>/artista-filmcamp und <owner>/artista-filmcamp-tools,
passend zum Repo. DATABASE_URL-Host, Backup-Host und Betriebsdoku
entsprechend angepasst.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Die Pipeline leitete den Image-Namen vom Repo "Artista-Filmcamp" ab. Das
Produkt ist das ARTISTA MODELCAMP 2027: Images heissen jetzt fest
<owner>/artista-modelcamp und <owner>/artista-modelcamp-tools, passend zu
Overlay und Betriebsdoku.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
next build versuchte /admin statisch zu rendern. currentAdmin() rief dabei
getAuth() vor headers() auf und scheiterte ohne BETTER_AUTH_SECRET im
Build-Container. Jetzt werden zuerst die Request-Header gelesen, wodurch
alle Admin-Routen dynamisch sind und Auth erst zur Laufzeit geladen wird.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
