Gestion des Secrets

4. Gestion des Secrets #

Variables d’environnement, fichiers, Secrets Kubernetes et HashiCorp Vault : protéger et faire tourner les secrets de Grafana Alloy.

Pourquoi les secrets demandent une attention particulière #

Un collecteur de télémétrie manipule beaucoup d'identifiants : clés d'API Grafana Cloud, mots de passe Mimir ou Loki, jetons de Datadog ou de Dynatrace, certificats TLS, identifiants de bases de données à superviser. Le fichier config.alloy, lui, est fait pour être versionné, relu et partagé. Un secret écrit en clair dans ce fichier se retrouve dans Git, dans les sauvegardes, dans les captures d'écran et dans les tickets de support.

Grafana Alloy répond à ce problème de trois façons : un type de valeur dédié (secret), des sources de secrets (variables d'environnement, fichiers, Kubernetes, Vault) et une réévaluation automatique lorsque le secret change. La vidéo de la session présente la démarche ; cet article la détaille, exemples à l'appui.

// ❌ À ne jamais faire : le jeton finit dans Git, dans les sauvegardes et dans les tickets
prometheus.remote_write "cloud" {
  endpoint {
    url = "https://prometheus-prod-01-eu-west-0.grafana.net/api/prom/push"
    basic_auth {
      username = "123456"
      password = "glc_eyJvIjoiMTIzNDU2Iiwibi..."
    }
  }
}

Le type secret : ce qu'Alloy masque, et ce qu'il ne masque pas #

Les attributs sensibles des composants, comme password, bearer_token ou api_key, sont de type secret. Une valeur de ce type n'est jamais affichée : l'interface d'Alloy (port 12345) et les journaux montrent (secret) à la place.

À retenir : le masquage protège l'affichage, pas le stockage. Le secret reste lisible là où il est stocké (variable d'environnement, fichier, Secret Kubernetes) : c'est là qu'il faut restreindre les accès.

Méthode 1 : les variables d'environnement #

C'est la méthode la plus simple et la plus portable : la configuration lit le secret avec sys.env(), et c'est l'outil de déploiement qui l'injecte.

// Variables d'environnement : simple et universel (Docker, systemd, Kubernetes)
prometheus.remote_write "cloud" {
  endpoint {
    url = sys.env("GRAFANA_CLOUD_PROM_URL")
    basic_auth {
      username = sys.env("GRAFANA_CLOUD_PROM_USER")
      password = sys.env("GRAFANA_CLOUD_API_KEY")   // converti en secret par l'attribut password
    }
  }
}

# systemd : /etc/default/alloy (droits 600, propriétaire root)
GRAFANA_CLOUD_PROM_URL=https://prometheus-prod-01-eu-west-0.grafana.net/api/prom/push
GRAFANA_CLOUD_PROM_USER=123456
GRAFANA_CLOUD_API_KEY=glc_xxxxxxxx

# Docker : fichier .env non versionné (ajouté au .gitignore)
docker run --env-file ./alloy.env -v ./config.alloy:/etc/alloy/config.alloy grafana/alloy:latest \
  run /etc/alloy/config.alloy

Avantages : rien à installer, fonctionne partout. Limites : la valeur est visible par quiconque peut inspecter le processus (docker inspect, /proc/<pid>/environ), et un changement impose un redémarrage d'Alloy.

Méthode 2 : un fichier de secret lu par local.file #

Le secret est déposé dans un fichier aux droits restreints, par Docker, Kubernetes, Ansible ou un agent Vault. Alloy le lit avec local.file et le surveille : si le fichier change, par exemple lors d'une rotation de clé, les composants qui l'utilisent sont reconfigurés sans redémarrage.

// Fichier monté : le secret ne transite ni par l'environnement ni par la configuration
local.file "api_key" {
  filename  = "/run/secrets/grafana_cloud_api_key"
  is_secret = true              // valeur de type secret : masquée dans l'UI et les journaux
}

loki.write "cloud" {
  endpoint {
    url = sys.env("GRAFANA_CLOUD_LOKI_URL")
    basic_auth {
      username = sys.env("GRAFANA_CLOUD_LOKI_USER")
      password = local.file.api_key.content
    }
  }
}

# docker-compose.yml : secret Docker monté dans /run/secrets
services:
  alloy:
    image: grafana/alloy:latest
    command: run /etc/alloy/config.alloy --server.http.listen-addr=0.0.0.0:12345
    volumes:
      - ./config.alloy:/etc/alloy/config.alloy:ro
    secrets:
      - grafana_cloud_api_key
secrets:
  grafana_cloud_api_key:
    file: ./secrets/grafana_cloud_api_key.txt   # droits 600, hors du dépôt Git

Rotation sans coupure : remplacez le contenu du fichier, Alloy détecte la modification et rouvre les connexions avec la nouvelle clé. Gardez l'ancienne clé valide quelques minutes côté serveur, le temps de la bascule.

Méthode 3 : les Secrets Kubernetes #

Sur Kubernetes, deux approches coexistent. La première monte le Secret en variable d'environnement ou en fichier via le chart Helm, puis revient aux méthodes 1 et 2. La seconde utilise remote.kubernetes.secret, qui lit le Secret directement dans l'API Kubernetes et suit ses modifications.

# values.yaml du chart Helm grafana/alloy : secret exposé en variable d'environnement
alloy:
  extraEnv:
    - name: GRAFANA_CLOUD_API_KEY
      valueFrom:
        secretKeyRef:
          name: grafana-cloud
          key: api-key

// Lecture directe d'un Secret Kubernetes (le compte de service d'Alloy doit pouvoir le lire)
remote.kubernetes.secret "mimir" {
  namespace = "monitoring"
  name      = "mimir-credentials"
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "https://mimir.example.com/api/v1/push"
    basic_auth {
      username = convert.nonsensitive(remote.kubernetes.secret.mimir.data["username"])
      password = remote.kubernetes.secret.mimir.data["password"]
    }
  }
}

# Droits minimaux : lire UN secret précis, dans UN namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: alloy-read-mimir-credentials
  namespace: monitoring
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["mimir-credentials"]
    verbs: ["get", "watch", "list"]

Avec remote.kubernetes.secret, il n'y a ni volume ni redémarrage du pod : la modification du Secret est prise en compte en quelques secondes. En contrepartie, le compte de service d'Alloy doit avoir le droit de lire ce Secret ; limitez-le avec resourceNames.

Méthode 4 : HashiCorp Vault #

Pour les organisations qui centralisent leurs secrets dans Vault, le composant remote.vault lit un chemin du coffre et le relit périodiquement. Il gère plusieurs méthodes d'authentification : auth.token, auth.approle, auth.kubernetes, auth.aws, auth.gcp, auth.userpass…

// HashiCorp Vault : authentification Kubernetes, relecture toutes les 5 minutes
remote.vault "mimir" {
  server = "https://vault.example.com:8200"
  path   = "secret/data/monitoring/mimir"     // moteur KV v2

  auth.kubernetes {
    role = "alloy"
  }

  reread_frequency = "5m"
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "https://mimir.example.com/api/v1/push"
    bearer_token = remote.vault.mimir.data["token"]
  }
}

Le jeton d'authentification à Vault est lui-même un secret. Préférez une authentification sans secret statique (auth.kubernetes, auth.aws) ; sinon, lisez le jeton avec local.file et is_secret = true.

Quelle méthode choisir ? #

Erreurs courantes et bonnes pratiques #

• Secret en clair dans config.alloy : ajoutez un contrôle dans la CI (gitleaks, git grep) et révoquez immédiatement toute clé publiée par erreur.
• convert.nonsensitive() utilisé pour « faire passer » une erreur : le secret devient visible dans l'interface. Réservez cette fonction aux valeurs réellement publiques, comme un nom d'utilisateur.
• Fichier de secret lisible par tous : droits 600, propriétaire l'utilisateur alloy.
• Interface d'Alloy exposée sur Internet : les secrets y sont masqués, mais la topologie et les URL des backends restent visibles. Écoutez sur 127.0.0.1 ou protégez le port 12345.
• Un secret partagé par tous les environnements : utilisez une clé par environnement et par usage (écriture des métriques, écriture des logs), avec le minimum de droits.

# Créer le secret Kubernetes sans l'écrire dans un fichier versionné
kubectl -n monitoring create secret generic mimir-credentials \
  --from-literal=username=alloy --from-literal=password="$(openssl rand -base64 24)"

# Protéger un fichier de secret sur une VM
sudo install -m 600 -o alloy -g alloy /dev/stdin /etc/alloy/secrets/api_key <<< "glc_xxxxxxxx"

# Vérifier qu'aucun secret n'est versionné
git grep -nE "glc_|password *= *\"" -- '*.alloy'

# Contrôler dans l'interface que la valeur apparaît bien comme (secret)
curl -s http://localhost:12345/api/v0/web/components | grep -c secret