Fournir les secrets au runner¶

Une source ne contient qu'une référence vers un secret, jamais sa valeur. Cette page dit où poser la valeur, selon la façon dont vous avez déployé votre runner.

Les trois formes de référence¶

env://NOM_DE_VARIABLE — la variable d'environnement de ce nom, dans le processus du runner.
file://nom_de_fichier — un fichier de ce nom, dans le dossier des secrets du runner.
static://cle — une clé de la table de secrets statiques, écrite dans la configuration du runner.

Le détail de la syntaxe, y compris pour un plan (secret://…), est dans Moteur de restauration — Les secrets.

Une référence env:// ne lit jamais une variable dont le nom commence par RESTOREPROOF_ : ces variables règlent le runner lui-même (sa clé d'API, les hôtes et les dossiers qu'il a le droit d'atteindre), et un plan ne doit pas pouvoir les lire. Donnez à vos secrets un autre nom, S3_SECRET_KEY par exemple.

Ce que le runner fait de la valeur¶

Le runner résout la référence au moment où il en a besoin et garde la valeur pour lui. Pendant toute l'exécution, il retient chaque valeur qu'il a résolue et la remplace par [REDACTED] dans tout ce qu'il envoie à RestoreProof : les messages d'erreur des étapes, le rapport, ses mesures et ses journaux. Si une commande affiche votre mot de passe, ou si une sonde le recopie dans son message, c'est [REDACTED] qui arrive dans l'application.

Une valeur très courte est masquée elle aussi, partout où elle apparaît. Un secret de deux ou trois caractères rend donc les messages difficiles à lire, sans rien laisser fuir : préférez des secrets longs.

Ce que l'application vous montre¶

La page du runner affiche une carte Secrets à fournir sur ce runner, avec une pastille verte quand tout se résout, rouge quand il manque au moins une référence. Elle liste, source par source, chaque référence attendue et son état — résolue, manquante, ou pas encore rapportée si le runner ne s'est pas encore synchronisé.
La page d'une source montre, sous chaque référence, une ligne par runner de l'organisation avec son état sur cette référence précise : utile dès que vous avez plus d'un runner.
L'assistant de déploiement (Parc de runners → Ajouter un runner) ajoute directement les variables et les montages nécessaires à la commande qu'il vous donne, et propose un encart Secrets attendus par vos sources avec les blocs prêts à copier ci-dessous.

Ces trois écrans lisent le même rapport : celui que le runner envoie à chaque synchronisation de ses sources, sans jamais y mettre une valeur.

Où poser la valeur, selon votre déploiement¶

L'exemple ci-dessous suppose une source S3 hébergée sur s3.fr-par.scw.cloud, avec deux références : env://S3_ACCESS_KEY pour la clé d'accès, file://minio-secret pour la clé secrète. La variable RESTOREPROOF_FETCH_HOSTS autorise le runner à joindre cet hôte : voir ce que le runner a le droit d'atteindre. Remplacez <à compléter> par vos propres valeurs, et /chemin/vers/secrets par un dossier réel de votre machine.

DockerDocker ComposeKubernetesBinaire

La convention du runner est /etc/restoreproof/secrets : montez-y un dossier de votre machine, en lecture seule, et posez-y un fichier par référence file://. Une référence env:// se passe d'un fichier, une variable d'environnement suffit.

mkdir -p /chemin/vers/secrets
printf '%s' '<à compléter>' > /chemin/vers/secrets/minio-secret
chmod 600 /chemin/vers/secrets/minio-secret

Ajoutez ensuite les deux lignes à votre docker run, après les volumes déjà présents :

docker run -d \
  --name restoreproof-runner \
  --restart unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v restoreproof-work:/var/lib/restoreproof \
  -e RESTOREPROOF_API_KEY="<clé API>" \
  -e RESTOREPROOF_URL="<adresse du canal>" \
  -e RESTOREPROOF_FETCH_HOSTS="s3.fr-par.scw.cloud" \
  -e S3_ACCESS_KEY=<à compléter> \
  -v /chemin/vers/secrets:/etc/restoreproof/secrets:ro \
  ghcr.io/kolapsis/restoreproof/runner:latest

Une référence static:// ne se pose pas par une variable ou un montage : elle demande un fichier de configuration monté sur /etc/restoreproof/config.yaml, avec la clé écrite sous secrets.static.<clé>: "<à compléter>".

Même convention que Docker : un dossier monté en lecture seule sur /etc/restoreproof/secrets, un fichier par référence file://.

mkdir -p /chemin/vers/secrets
printf '%s' '<à compléter>' > /chemin/vers/secrets/minio-secret
chmod 600 /chemin/vers/secrets/minio-secret

services:
  runner:
    image: ghcr.io/kolapsis/restoreproof/runner:latest
    environment:
      RESTOREPROOF_API_KEY: "<clé API>"
      RESTOREPROOF_URL: "<adresse du canal>"
      RESTOREPROOF_FETCH_HOSTS: "s3.fr-par.scw.cloud"
      S3_ACCESS_KEY: <à compléter>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - restoreproof-work:/var/lib/restoreproof
      - /chemin/vers/secrets:/etc/restoreproof/secrets:ro

Une référence static:// demande, comme sur Docker, un fichier de configuration monté plutôt qu'une variable — secrets.static.<clé>: "<à compléter>".

Un Secret porte les deux formes : ses clés servent à la fois de variables d'environnement et de fichiers.

apiVersion: v1
kind: Secret
metadata:
  name: restoreproof-runner-secrets
  namespace: restoreproof
type: Opaque
stringData:
  S3_ACCESS_KEY: "<à compléter>"
  minio-secret: "<à compléter>"

Puis un fichier de valeurs pour le chart, à ajouter à votre helm install ou helm upgrade avec -f runner-secrets.values.yaml :

extraEnv:
  - name: S3_ACCESS_KEY
    valueFrom:
      secretKeyRef:
        name: restoreproof-runner-secrets
        key: S3_ACCESS_KEY

secrets:
  additional:
    - name: sources
      secretName: restoreproof-runner-secrets
      mountPath: /etc/restoreproof/secrets

secrets.additional monte tout le Secret sous /etc/restoreproof/secrets : les clés déclarées comme variables d'environnement (S3_ACCESS_KEY ci-dessus) y apparaissent donc aussi comme fichiers. Sans conséquence — le runner ne lit que ce que la référence lui désigne.

Une référence static:// demande, elle aussi, un fichier de configuration monté plutôt qu'une variable ou un Secret — secrets.static.<clé>: "<à compléter>".

La convention est la même : un dossier /etc/restoreproof/secrets, un fichier par référence file://, une section secrets: dans config.yaml.

secrets:
  env_prefix: ""
  file_dir: /etc/restoreproof/secrets
  static: {}

export S3_ACCESS_KEY='<à compléter>'

mkdir -p /etc/restoreproof/secrets
printf '%s' '<à compléter>' > /etc/restoreproof/secrets/minio-secret
chmod 600 /etc/restoreproof/secrets/minio-secret

Une référence static:// s'écrit directement dans config.yaml, sous secrets.static.<clé>: "<à compléter>" : pas de montage à prévoir, le fichier est déjà le vôtre.

Retrouver le gabarit sans repasser par l'écran¶

Le runner peut imprimer lui-même la section secrets: attendue — les clés static déjà connues, valeurs vidées, jamais un appel réseau :

# Docker
docker run --rm ghcr.io/kolapsis/restoreproof/runner:latest -print-secrets-template

# Docker Compose
docker compose run --rm runner -print-secrets-template

# Binaire
./restoreproof-runner -print-secrets-template

C'est le même gabarit que celui préaffiché par secrets.static dans la configuration téléchargeable depuis la page du runner.

`env_prefix`¶

Si votre configuration porte un secrets.env_prefix non vide, il est ajouté devant le nom de chaque référence env:// avant la lecture de la variable : une référence env://S3_ACCESS_KEY avec env_prefix: "RP_" lit la variable RP_S3_ACCESS_KEY. Utile pour éviter une collision avec une variable déjà prise par un autre outil sur la même machine. Le nom obtenu ne doit pas commencer par RESTOREPROOF_, pour la raison donnée plus haut : un préfixe RESTOREPROOF_SECRET_ ferait refuser toutes les références env://.

Après modification, redémarrez le runner ; la carte passe au vert au battement suivant.