From f909978dcd39ae4951e0aa6fd37288a2a34d05ad Mon Sep 17 00:00:00 2001
From: Ubuntu <nick@vm-management-200.stabify.de>
Date: Wed, 14 Jan 2026 00:03:20 +0000
Subject: [PATCH] fix ingress for rook ceph

---
 .gitignore                       |  4 +-
 setup_k3s_vault_auth.sh          | 63 +++++++++++++++++----------
 stabify-wiki/09-storage-minio.md | 74 --------------------------------
 terraform/locals.tf              |  6 +--
 4 files changed, 47 insertions(+), 100 deletions(-)
 delete mode 100644 stabify-wiki/09-storage-minio.md

diff --git a/.gitignore b/.gitignore
index f15c98b..aee81df 100644
--- a/.gitignore
+++ b/.gitignore
@@ -31,8 +31,10 @@ infrastructure/apps/vault/certs/
 .DS_Store
 
 # CI/CD Strategy
-00-CICD-Strategy/
+stabify-gitops/
 
+# WIKI
+stabify-wiki/
 # OS generated
 Thumbs.db
 
diff --git a/setup_k3s_vault_auth.sh b/setup_k3s_vault_auth.sh
index 5aaf821..9bb90df 100755
--- a/setup_k3s_vault_auth.sh
+++ b/setup_k3s_vault_auth.sh
@@ -1,50 +1,69 @@
 #!/bin/bash
 set -e
 
-# Umgebungsvariablen prüfen
-if [ -z "$VAULT_ADDR" ] || [ -z "$VAULT_TOKEN" ]; then
-    echo "Bitte setze VAULT_ADDR und VAULT_TOKEN!"
+if [ -z "$VAULT_ADDR" ]; then
+    echo "Setze VAULT_ADDR!"
     exit 1
 fi
 
-echo "--- Vault Kubernetes Auth Setup ---"
+echo "--- Vault Kubernetes Auth Setup (Token Reviewer Method) ---"
 
-# 1. Kubernetes Auth aktivieren (falls nicht aktiv)
+# 1. Auth aktivieren
 vault auth enable kubernetes || true
 
-# 2. Kubernetes Config holen (vom lokalen kubectl Context, muss auf K3s zeigen)
-# Wir brauchen das CA Cert und die API URL.
-# HINWEIS: Da wir von außen (VM Management) auf K3s (10.100.40.5) zugreifen, nutzen wir diese URL.
-
-# Hole ServiceAccount Token vom K3s Cluster (wir erstellen temporär einen SA, um die Config zu holen oder nutzen den default)
-# Einfacher: Wir nutzen die Config, die Vault braucht, um K3s zu validieren.
-# Da K3s Token Auth nutzt, müssen wir Vault sagen, wie er Token validiert -> via TokenReview API.
-
-K8S_HOST="https://10.100.40.5:6443"
-# Das CA Cert des Clusters (muss man sich besorgen, z.B. aus /etc/rancher/k3s/k3s.yaml auf dem Master)
-# Wir kopieren es uns einfach kurz via SSH, falls nicht lokal vorhanden.
+# 2. CA Cert holen
+echo "Hole CA Cert..."
 ssh -i ~/.ssh/id_ed25519_ansible_prod ansible@10.100.40.10 "sudo cat /var/lib/rancher/k3s/server/tls/server-ca.crt" > k3s-ca.crt
 
+# 3. ServiceAccount für TokenReview erstellen (falls nicht existiert)
+echo "Erstelle ServiceAccount für Vault..."
+ssh -i ~/.ssh/id_ed25519_ansible_prod ansible@10.100.40.10 "sudo kubectl create sa vault-auth -n kube-system --dry-run=client -o yaml | sudo kubectl apply -f -"
+ssh -i ~/.ssh/id_ed25519_ansible_prod ansible@10.100.40.10 "sudo kubectl create clusterrolebinding vault-auth-binding --clusterrole=system:auth-delegator --serviceaccount=kube-system:vault-auth --dry-run=client -o yaml | sudo kubectl apply -f -"
+
+# 4. Long-Lived Token Secret erstellen
+echo "Erstelle Token Secret..."
+ssh -i ~/.ssh/id_ed25519_ansible_prod ansible@10.100.40.10 "cat <<EOF | sudo kubectl apply -f -
+apiVersion: v1
+kind: Secret
+metadata:
+  name: vault-auth-token
+  namespace: kube-system
+  annotations:
+    kubernetes.io/service-account.name: vault-auth
+type: kubernetes.io/service-account-token
+EOF"
+
+# 5. Token auslesen
+echo "Lese Token aus..."
+REVIEWER_TOKEN=$(ssh -i ~/.ssh/id_ed25519_ansible_prod ansible@10.100.40.10 "sudo kubectl get secret vault-auth-token -n kube-system -o jsonpath='{.data.token}' | base64 -d")
+
+if [ -z "$REVIEWER_TOKEN" ]; then
+    echo "Fehler: Konnte Token nicht lesen!"
+    exit 1
+fi
+
+# 6. Config schreiben (MIT token_reviewer_jwt)
+echo "Schreibe Vault Config..."
 vault write auth/kubernetes/config \
-    kubernetes_host="$K8S_HOST" \
+    kubernetes_host="https://10.100.40.5:6443" \
     kubernetes_ca_cert=@k3s-ca.crt \
-    disable_iss_validation=true
+    token_reviewer_jwt="$REVIEWER_TOKEN" \
+    disable_iss_validation=true \
+    disable_local_ca_jwt=false
 
 rm k3s-ca.crt
 
-# 3. Policy erstellen (Lesezugriff auf alles unter secret/)
+# 7. Policy & Rolle (bleibt gleich)
 vault policy write k3s-secrets-reader - <<EOF
 path "secret/data/*" {
   capabilities = ["read"]
 }
 EOF
 
-# 4. Rolle erstellen
-# Erlaubt dem ServiceAccount 'external-secrets' im Namespace 'external-secrets' den Login.
 vault write auth/kubernetes/role/external-secrets-role \
     bound_service_account_names=external-secrets \
     bound_service_account_namespaces=external-secrets \
     policies=k3s-secrets-reader \
     ttl=24h
 
-echo "Vault Kubernetes Auth erfolgreich konfiguriert!"
+echo "Fertig! Bitte ESO Pod neustarten."
diff --git a/stabify-wiki/09-storage-minio.md b/stabify-wiki/09-storage-minio.md
deleted file mode 100644
index 10b7a8f..0000000
--- a/stabify-wiki/09-storage-minio.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# MinIO (S3 Object Storage) Setup
-
-MinIO wird als lokaler S3-kompatibler Object Storage in Kubernetes betrieben. Es dient als Speicherziel für Anwendungen wie Outline, Backups und Medien-Uploads.
-
-## 1. Architektur & Storage
-MinIO läuft als einzelner Pod (`Deployment` mit Replicas=1) und nutzt einen Kubernetes `PersistentVolumeClaim` (PVC).
-
-- **PVC Größe:** 50Gi (Initial)
-- **Storage Class:** `local-path` (Standard K3s)
-- **Physischer Speicher:** Die Daten landen auf der VM (`vm-k3s-master-400`) im Verzeichnis `/var/lib/rancher/k3s/storage/`.
-
-### Erweiterung (Proxmox)
-Wenn der Speicherplatz der VM zur Neige geht:
-1.  In Proxmox die VM-Disk vergrößern (oder eine zweite Disk hinzufügen).
-2.  Im Linux-Gast (`vm-k3s-master-400`) das Dateisystem erweitern (`resize2fs`).
-3.  Die Daten für MinIO wachsen automatisch mit dem verfügbaren Platz auf der Partition.
-
-## 2. Vault Secrets
-MinIO benötigt einen Root User und ein Passwort. Diese werden in Vault gespeichert.
-
-**Pfad:** `secret/apps/minio`
-
-| Key | Value | Beschreibung |
-| :--- | :--- | :--- |
-| `root_user` | `admin` | Der Benutzername für den Admin-Login. |
-| `root_password` | `...` | Ein starkes, generiertes Passwort. |
-
-### Vault Setup Befehle
-```bash
-# 1. Passwort generieren
-MINIO_PW=$(openssl rand -base64 24)
-
-# 2. In Vault schreiben
-vault kv put secret/apps/minio root_user="admin" root_password="$MINIO_PW"
-```
-
-## 3. Zugriff
-Das System stellt zwei Domains bereit:
-
-1.  **Console (Web UI):** `https://minio.apps.k3s.stabify.de`
-    - Hier loggst du dich ein, erstellst Buckets, User und Access Keys.
-2.  **S3 API:** `https://s3.apps.k3s.stabify.de`
-    - Diesen Endpunkt tragen Applikationen (wie Outline) als "S3 Endpoint" ein.
-
-## 4. Bucket Naming Convention 🪣
-Damit wir im Chaos nicht untergehen, nutzen wir folgende Struktur für Bucket-Namen:
-
-`[app-name]-[environment]-[purpose]`
-
-- **app-name:** Name der Anwendung (z.B. `outline`, `authentik`, `gitlab`).
-- **environment:** `prod` (Produktion) oder `dev` (Entwicklung).
-- **purpose:** Optional, was drin ist (z.B. `media`, `backups`, `logs`).
-
-### Beispiele
-| Bucket Name | Verwendung |
-| :--- | :--- |
-| `outline-prod-media` | Bilder und Uploads für das Wiki (Outline). |
-| `authentik-prod-static` | Statische Assets oder Uploads für Authentik. |
-| `postgres-prod-backups` | Datenbank-Dumps (z.B. via Wal-G oder Scripts). |
-| `loki-prod-logs` | Log-Speicher für Loki (falls verwendet). |
-
-## 5. Verwendung in Apps (z.B. Outline)
-Um MinIO in einer App zu nutzen:
-1.  Logge dich in die MinIO Console ein.
-2.  Erstelle einen **Bucket** (z.B. `outline-storage`).
-3.  Setze den Bucket auf **Public** (wenn nötig) oder konfiguriere eine Policy.
-    - *Empfehlung für Outline:* Bucket Access Policy auf `custom` und `ReadOnly` für `*` (Anonymous), damit Bilder im Wiki öffentlich sichtbar sind (wenn gewünscht), oder besser: Nutze Presigned URLs.
-4.  Erstelle einen **Service Account** (Access Key & Secret Key).
-5.  Konfiguriere die App mit:
-    - **Endpoint:** `https://s3.apps.k3s.stabify.de`
-    - **Region:** `eu-central-1` (oder was du eingestellt hast, MinIO ist das meist egal, Standard ist oft `us-east-1`).
-    - **Access Key:** (aus Service Account)
-    - **Secret Key:** (aus Service Account)
-    - **Bucket:** `outline-storage`
diff --git a/terraform/locals.tf b/terraform/locals.tf
index 1bef31c..285fcc2 100644
--- a/terraform/locals.tf
+++ b/terraform/locals.tf
@@ -13,9 +13,9 @@ locals {
     "vm-docker-traefik-302" = { id = 302, cores = 1, memory = 2048, vlan = 30, tags = "docker,ingress", ip = "10.100.30.12", gw = "10.100.30.1" }
 
     # VLAN 40: K3s (HA Control Plane)
-    "vm-k3s-master-400"     = { id = 400, cores = 2, memory = 4096, vlan = 40, tags = "k3s,master",     ip = "10.100.40.10", gw = "10.100.40.1" }
-    "vm-k3s-master-401"     = { id = 401, cores = 2, memory = 4096, vlan = 40, tags = "k3s,master",     ip = "10.100.40.11", gw = "10.100.40.1" }
-    "vm-k3s-master-402"     = { id = 402, cores = 2, memory = 4096, vlan = 40, tags = "k3s,master",     ip = "10.100.40.12", gw = "10.100.40.1" }
+    "vm-k3s-master-400"     = { id = 400, cores = 2, memory = 10240, vlan = 40, tags = "k3s,master",     ip = "10.100.40.10", gw = "10.100.40.1" }
+    "vm-k3s-master-401"     = { id = 401, cores = 2, memory = 10240, vlan = 40, tags = "k3s,master",     ip = "10.100.40.11", gw = "10.100.40.1" }
+    "vm-k3s-master-402"     = { id = 402, cores = 2, memory = 10240, vlan = 40, tags = "k3s,master",     ip = "10.100.40.12", gw = "10.100.40.1" }
 
     # VLAN 90: Bastion
     "vm-bastion-900"        = { id = 900, cores = 1, memory = 2048, vlan = 90, tags = "bastion",        ip = "10.100.90.10", gw = "10.100.90.1" }