fix ingress for rook ceph
This commit is contained in:
Ubuntu
4
.gitignore
vendored
4
.gitignore
vendored
@@ -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
|
||||
|
||||
|
||||
@@ -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."
|
||||
|
||||
@@ -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`
|
||||
@@ -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" }
|
||||
|
||||
Reference in New Issue
Block a user