fix ingress for rook ceph

This commit is contained in:
Ubuntu
2026-01-14 00:03:20 +00:00
parent a8c0735e13
commit f909978dcd
4 changed files with 47 additions and 100 deletions

4
.gitignore vendored
View File

@@ -31,8 +31,10 @@ infrastructure/apps/vault/certs/
.DS_Store .DS_Store
# CI/CD Strategy # CI/CD Strategy
00-CICD-Strategy/ stabify-gitops/
# WIKI
stabify-wiki/
# OS generated # OS generated
Thumbs.db Thumbs.db

View File

@@ -1,50 +1,69 @@
#!/bin/bash #!/bin/bash
set -e set -e
# Umgebungsvariablen prüfen if [ -z "$VAULT_ADDR" ]; then
if [ -z "$VAULT_ADDR" ] || [ -z "$VAULT_TOKEN" ]; then echo "Setze VAULT_ADDR!"
echo "Bitte setze VAULT_ADDR und VAULT_TOKEN!"
exit 1 exit 1
fi 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 vault auth enable kubernetes || true
# 2. Kubernetes Config holen (vom lokalen kubectl Context, muss auf K3s zeigen) # 2. CA Cert holen
# Wir brauchen das CA Cert und die API URL. echo "Hole CA Cert..."
# 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.
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 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 \ vault write auth/kubernetes/config \
kubernetes_host="$K8S_HOST" \ kubernetes_host="https://10.100.40.5:6443" \
kubernetes_ca_cert=@k3s-ca.crt \ 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 rm k3s-ca.crt
# 3. Policy erstellen (Lesezugriff auf alles unter secret/) # 7. Policy & Rolle (bleibt gleich)
vault policy write k3s-secrets-reader - <<EOF vault policy write k3s-secrets-reader - <<EOF
path "secret/data/*" { path "secret/data/*" {
capabilities = ["read"] capabilities = ["read"]
} }
EOF EOF
# 4. Rolle erstellen
# Erlaubt dem ServiceAccount 'external-secrets' im Namespace 'external-secrets' den Login.
vault write auth/kubernetes/role/external-secrets-role \ vault write auth/kubernetes/role/external-secrets-role \
bound_service_account_names=external-secrets \ bound_service_account_names=external-secrets \
bound_service_account_namespaces=external-secrets \ bound_service_account_namespaces=external-secrets \
policies=k3s-secrets-reader \ policies=k3s-secrets-reader \
ttl=24h ttl=24h
echo "Vault Kubernetes Auth erfolgreich konfiguriert!" echo "Fertig! Bitte ESO Pod neustarten."

View File

@@ -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`

View File

@@ -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" } "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) # 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-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 = 4096, vlan = 40, tags = "k3s,master", ip = "10.100.40.11", 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 = 4096, vlan = 40, tags = "k3s,master", ip = "10.100.40.12", 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 # 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" } "vm-bastion-900" = { id = 900, cores = 1, memory = 2048, vlan = 90, tags = "bastion", ip = "10.100.90.10", gw = "10.100.90.1" }