Files
Xor290 dfc62c305d
ci-api / test (push) Successful in 25m49s
chore: build
2026-08-18 20:07:52 +02:00

95 lines
4.1 KiB
YAML

# Prérequis (à faire une seule fois, hors de ce manifeste — même logique que
# deploy/cert-manager/ et deploy/longhorn/, un composant partagé du cluster,
# jamais par démo) :
#
# 1. Créer le bucket S3 (ou compatible S3 : MinIO, Backblaze B2, OVH,
# Scaleway, Wasabi...) qui recevra les sauvegardes, avec une paire de
# clés d'accès dédiée (droits limités à ce bucket).
#
# 2. Créer le fichier de credentials LOCALEMENT (ne jamais le committer) :
# cat > credentials-velero <<EOF
# [default]
# aws_access_key_id=<votre_access_key>
# aws_secret_access_key=<votre_secret_key>
# EOF
#
# 3. Créer le namespace + le secret à partir de ce fichier :
# kubectl create namespace velero
# kubectl create secret generic cloud-credentials \
# --namespace velero --from-file cloud=./credentials-velero
# rm credentials-velero
#
# 4. Renseigner bucket / region / s3Url ci-dessous selon votre fournisseur,
# puis installer Velero (chart officiel, version vérifiée) :
# helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
# helm install velero vmware-tanzu/velero \
# --namespace velero --version 12.1.0 \
# -f deploy/velero/values.yaml
# Rien d'autre à appliquer : les plannings de sauvegarde sont créés
# dynamiquement par démo par le control-plane, voir deploy/velero/schedule.yml.
#
# 5. Sécurité du bucket — à vérifier CÔTÉ RustFS/MinIO (rien de tout ça ne
# se configure depuis ce repo) : chaque sauvegarde contient les Secrets
# K8s en clair (mots de passe postgres/redis, JWT, tokens Telegram...)
# de toutes les démos.
# - Chiffrement at-rest activé sur le bucket/disque côté RustFS/MinIO
# (indépendant du header SSE ci-dessous, qui ne fait que le demander
# au serveur).
# - Clé d'accès dédiée à ce bucket UNIQUEMENT (voir étape 1) — jamais la
# clé d'admin du cluster de stockage.
# - Versioning ou object-lock (WORM) activé si le fournisseur le
# supporte : sans ça, une clé compromise peut aussi supprimer/écraser
# l'historique des sauvegardes, pas seulement les données live.
#
# Pourquoi File System Backup (kopia) plutôt que des snapshots CSI Longhorn :
# ça fonctionne indépendamment du provisioner de stockage (pas de
# VolumeSnapshotClass/CRD supplémentaire à maintenir), et couvre aussi bien
# les PVC postgres/redis/uploads que le reste de chaque namespace de démo
# (Secrets, ConfigMaps, Deployments...) pour une restauration complète, pas
# seulement les données.
# velero-plugin-for-aws v1.14.2 : dernière version compatible avec Velero
# 1.18.x (appVersion de ce chart) — vérifié sur le tableau de compatibilité
# du plugin. Fonctionne aussi bien avec AWS S3 qu'avec un stockage
# compatible S3 (MinIO, OVH, Backblaze...).
initContainers:
- name: velero-plugin-for-aws
image: velero/velero-plugin-for-aws:v1.14.2
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /target
name: plugins
credentials:
useSecret: false
existingSecret: cloud-credentials
configuration:
backupStorageLocation:
- name: default
provider: aws
# Nom du bucket créé à l'étape 1. Requis.
bucket: "backup-omnex"
default: true
credential:
name: cloud-credentials
key: cloud
config:
region: "us-east-1"
s3Url: "https://backup-omnex.uber-stup.club"
s3ForcePathStyle: "true"
insecureSkipTLSVerify: "false"
# Pas de serverSideEncryption ici : ce RustFS refuse le SSE-S3 tant
# que RUSTFS_SSE_S3_MASTER_KEY (clé base64 32 octets) n'est pas
# configurée côté serveur ("InvalidRequest: SSE-S3 requires
# RUSTFS_SSE_S3_MASTER_KEY..."), réglage hors de portée depuis ce
# repo. Le transport reste chiffré (HTTPS) ; pour du chiffrement
# at-rest, configurer cette variable côté serveur RustFS puis
# remettre serverSideEncryption: "AES256" ici.
volumeSnapshotLocation: []
snapshotsEnabled: false
deployNodeAgent: true