Rôles et permissions

Le modèle tient en trois objets : une permission est un droit élémentaire, un rôle en regroupe plusieurs, une affectation lie un rôle à un porteur sur une ressource.

Les permissions

Une permission s’écrit <ressource>/<action> :

project/create   project/read
bucket/read      bucket/edit
run/create
catalog/read
experiment/create  experiment/read  experiment/edit

Elles sont élémentaires et non négociables : c’est ce que l’API vérifie, appel par appel. Un rôle qui ne contient pas run/create ne lance pas de run, quel que soit son nom.

Les rôles

Un rôle est un ensemble nommé de permissions. Ceux d’une installation type :

Rôle	Ce qu’il permet, en une phrase
Tenant Administrator	Administrer le locataire : utilisateurs, groupes, rôles, affectations, fournisseurs d’identité
Project Owner	Tout sur son projet : jobs, runs, buckets, secrets, membres du projet
Project Reader	Lire son projet sans rien y changer — le rôle qu’on donne par défaut
Bucket Reader	Lire les fichiers d’un bucket, sans droit sur le reste du projet

Le catalogue exact dépend de votre installation : GET /roles fait foi, pas ce tableau.

Les porteurs : trois sortes, un seul modèle

Porteur	Ce que c’est	Quand s’en servir
Utilisateur	Une personne	Cas courant
Groupe	Un ensemble de personnes, souvent fédéré depuis votre annuaire	Une équipe data de 3 à 15 personnes : c’est le seul moyen praticable de ne pas les nommer une à une
Identité / application	Un porteur non humain : l’identité sous laquelle tournent les jobs, le compte de service d’un agent IA	Tout ce qui n’est pas quelqu’un

Le point qui compte : un agent IA n’est pas une catégorie à part. Il porte les droits qu’on lui a donnés, soumis aux mêmes vérifications, et il se révoque comme un utilisateur.

Donner un droit

curl -s -X POST "$GRAAL_API/assignments" \
  -H "Authorization: Bearer $TOKEN" -H "X-Tenant: $TENANT" \
  -H 'Content-Type: application/vnd.graal.systems.v1.assignment+json' \
  -d '{"role_id":"<rôle>","principal_id":"<porteur>","resource_id":"<ressource>"}'

Dans la console, c’est l’écran Rôles et affectations, et la révocation est un bouton sur la ligne de l’affectation.

Le retirer

On révoque une affectation, jamais un rôle. Supprimer un rôle pour retirer un droit à une personne le retire à tout le monde ; c’est la faute classique.

curl -s -X DELETE "$GRAAL_API/assignments/<id>" \
  -H "Authorization: Bearer $TOKEN" -H "X-Tenant: $TENANT"

Donner ses droits à un agent ou à un script

1. Créez une application (POST /applications) — elle porte des identifiants machine.
2. Affectez-lui les rôles dont elle a besoin, sur les projets concernés uniquement.
3. Utilisez ses identifiants, jamais les vôtres.

Un script qui tourne avec le jeton d’une personne cesse de fonctionner le jour où cette personne part, et lui attribue au passage tous les droits de cette personne. C’est vrai partout ; ici, il y a un objet fait pour ça.

Ce que trace l’audit

Chaque affectation posée ou révoquée, comme chaque action faite avec les droits qu’elle donne, est attribuée à son acteur, humain ou agent, dans le journal d’audit (voir sécurité et gouvernance).

Pour aller plus loin

• Sécurité et gouvernance
• Agents IA (MCP) — les droits d’un agent, et ses garde-fous
• Concepts et vocabulaire