Aller au contenu
graal — documentation

Secrets et bibliothèques

Un job qui ne lit que des fichiers publics est un job de démonstration. Un job réel a besoin de son code, de ses dépendances et d’un identifiant pour joindre une base ou un stockage. Ces trois choses arrivent par trois chemins différents, et les confondre est la cause la plus fréquente d’un run qui échoue sur un accès refusé.

Les bibliothèques : ce qui arrive dans /workspace

Section intitulée « Les bibliothèques : ce qui arrive dans /workspace »

Une bibliothèque est un fichier que le planificateur dépose dans le conteneur du run avant de le démarrer. C’est le mécanisme par lequel arrive le code lui-même, pas seulement les dépendances.

Fenêtre de terminal
# 1. envoyer le fichier — l'API rend une clé
curl -s -X POST "$GRAAL_API/libraries" \
  -H "Authorization: Bearer $TOKEN" -H "X-Tenant: $TENANT" \
  -F file=@traitement.py
# → [{"key":"…","name":"traitement.py",…}]


# 2. référencer la clé dans le job
#    "libraries": [{"type": "file", "key": "<la clé rendue>"}]
#    "options":   {"type": "python", "file": "traitement.py", …}

options.file désigne le fichier tel qu’il apparaîtra dans /workspace, c’est-à-dire son nom d’origine — pas la clé.

Les dépendances Python

Section intitulée « Les dépendances Python »

L’image d’exécution python installe au démarrage ce qu’elle trouve dans /workspace : un requirements.txt, ou des archives (.whl, .tar.gz). Envoyez-les comme bibliothèques, au même titre que le code.

L’installation se fait sous l’utilisateur non privilégié du conteneur, pas en root : l’image est préparée pour ça. Vous n’avez rien à configurer.

Les secrets : ce qui n’a pas le droit de traîner

Section intitulée « Les secrets : ce qui n’a pas le droit de traîner »

Un secret de projet est scellé en base : chiffré en AES-256-GCM, avec une clé dérivée par locataire, et le nom de la clé sert de donnée authentifiée — un secret déplacé d’une entrée à une autre ne se déchiffre pas. Détail sur la page sécurité.

Au lancement d’un run, un conteneur d’initialisation rappelle l’API avec l’identité du job, récupère les secrets auxquels cette identité a droit, et les dépose dans un fichier du conteneur, sous /workspace/secrets/. Le job lit ce fichier.

Ce détour n’est pas de la cérémonie. Il donne trois choses qu’un passage par l’environnement ne donne pas :

  1. Le secret n’apparaît pas dans la définition du job, donc pas dans un export, pas dans une copie de configuration, pas dans une capture d’écran.
  2. Il n’apparaît pas dans l’environnement du processus, où n’importe quel sous-processus, trace d’erreur ou vidage de diagnostic le ramasserait.
  3. Les droits s’appliquent : c’est l’identité du job qui demande, pas celle de la personne qui a créé le job.

options.env : ce qu’il faut y mettre, et ce qu’il ne faut pas

Section intitulée « options.env : ce qu’il faut y mettre, et ce qu’il ne faut pas »
À mettre À ne pas y mettre
Le nom d’un bucket, un chemin, une date de traitement Un mot de passe, une clé d’API, un jeton
Un niveau de journalisation, un drapeau de fonctionnalité Une chaîne de connexion complète
L’adresse d’un service interne Tout ce dont la fuite vous obligerait à une rotation

La règle courte : l’environnement décrit, il n’authentifie pas.

La clé racine et les coffres existants

Section intitulée « La clé racine et les coffres existants »
  • La clé racine des secrets se génère une fois, à l’installation, et se sauvegarde : les secrets scellés avec elle ne s’ouvrent qu’avec elle (voir installation).
  • Aucun coffre tiers n’est requis. Un locataire qui en possède déjà un peut le désigner pour ses secrets.

Pour aller plus loin

Section intitulée « Pour aller plus loin »