# Livraison des alertes Prometheus vers Telegram (bot prospection).
#
# Alertmanager tourne dans le namespace `tools`, mais le token du bot vit dans Vault
# (kvv2/prospection/telegram). Le Secret `prospection-telegram` synchronisé par VSO est
# namespace-scoped (prospection) et non réutilisable ici. On resynchronise donc le même
# chemin kvv2 vers un Secret `alertmanager-telegram` dans `tools`, via un VaultAuth dédié
# (rôle k8s `alertmanager`, provisionné par hashicorp-vault/iac).
#
# NB: ce chart prometheus est en mode `tool.kind: SubChart`, donc les templates
# helm-chart*.yaml ne rendent rien ; ce fichier, lui, est rendu tel quel et appliqué par
# ArgoCD (app `prometheus`, destination namespace `tools`).
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: alertmanager-telegram
  namespace: tools
spec:
  # Dans le ns tools, VSO exige un vaultConnectionRef explicite (contrairement au ns
  # prospection qui hérite d'une connexion par défaut). On pointe la VaultConnection
  # `default` déjà présente dans tools (http://hashicorp-vault.tools.svc:8200).
  vaultConnectionRef: default
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: alertmanager
    serviceAccount: prometheus-alertmanager
    audiences:
      - vault
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: alertmanager-telegram
  namespace: tools
spec:
  type: kv-v2
  mount: kvv2
  path: prospection/telegram
  destination:
    name: alertmanager-telegram
    create: true
  refreshAfter: 1h
  vaultAuthRef: alertmanager-telegram
  # Alertmanager lit le token depuis un fichier monté au démarrage et ne recharge pas à
  # chaud un secret monté : on redémarre le StatefulSet quand le token change dans Vault.
  rolloutRestartTargets:
    - kind: StatefulSet
      name: prometheus-alertmanager