Aller au contenu principal

Les secrets, proprement

Débutant ⏱ 8 min secrets · config · production

Vous allez construire : une application dont la config ne contient aucun identifiant — et un deploy qui échoue bruyamment si un secret manque, au lieu d'expédier un pipeline cassé.

${secret:NAME} → résolu au deploy

Prérequis​

  • N'importe quelle application avec un sink ou un connecteur à identifiants.

1 · Stockez un secret en local​

pulse secret set ALERT_WEBHOOK https://hooks.example.com/T000/B000/xxxx

Stocké dans le magasin local de la CLI (fichier en mode 0600). Listez et supprimez avec pulse secret list · pulse secret rm NAME.

2 · Référencez-le — ne le collez jamais​

sink:
  kind: webhook
  url: ${secret:ALERT_WEBHOOK}

Deux formes de référence existent : ${secret:NAME} (magasin de la CLI) et ${env:VAR} (variable d'environnement). Le générateur émet déjà ces références pour les champs d'identifiants — suivez son exemple.

3 · Voyez le garde-fou en action​

pulse secret rm ALERT_WEBHOOK
pulse deploy .

Le deploy s'arrête avec une erreur nommée : la référence ${secret:ALERT_WEBHOOK} ne peut pas être résolue. Une config trouée n'atteint jamais le runtime.

4 · Restaurez et déployez proprement​

pulse secret set ALERT_WEBHOOK https://hooks.example.com/T000/B000/xxxx
pulse deploy .

Ce qui vient de se passer​

Les secrets sont résolus au moment du deploy, depuis l'extérieur du fichier. Le YAML que vous committez dans git porte des références, jamais des valeurs — le même fichier est donc sûr dans une PR, et la même application se déploie contre des identifiants dev ou prod en changeant ce que les références résolvent, pas le fichier.

Dépannage​

Où vit le magasin de secrets ?

pulse secret path vous le montre. C'est un fichier local avec des permissions propriétaire-seul (0600) — par développeur, par machine.

Ensuite​