Le contrôle d’accès basé sur les rôles (RBAC) vous permet de décider qui peut faire quoi dans votre organisation et vos projets, aussi bien via l’API que dans le tableau de bord. Les mêmes autorisations régissent les deux interfaces : si une personne peut appeler un point de terminaison (par exemple, /v1/chat/completions), elle peut utiliser la page correspondante du tableau de bord. Si elle ne dispose pas des autorisations nécessaires, les éléments d’interface concernés sont désactivés (comme le bouton Importer dans le Playground). Avec le RBAC, vous pouvez :
- Regrouper les utilisateurs et attribuer des autorisations à grande échelle
- Créer des rôles personnalisés avec exactement les autorisations dont vous avez besoin
- Définir la portée des accès au niveau de l’organisation ou du projet
- Appliquer des autorisations cohérentes dans le tableau de bord et l’API
Concepts clés
- Organisation : votre compte de premier niveau. Les rôles de l’organisation peuvent accorder un accès à tous les projets.
- Projet : un espace de travail pour les clés, les fichiers et les ressources. Les rôles du projet accordent un accès limité à ce projet.
- Groupes : des ensembles d’utilisateurs auxquels vous pouvez attribuer des rôles. Les groupes peuvent être synchronisés depuis votre fournisseur d’identité (via SCIM) pour que la liste de leurs membres reste automatiquement à jour.
- Rôles : des ensembles d’autorisations (comme Requêtes aux modèles ou Écriture de fichiers). Vous pouvez créer des rôles pour l’organisation dans les Paramètres de l’organisation, ou pour un projet spécifique dans les paramètres de ce projet. Une fois créés, les rôles de l’organisation ou du projet peuvent être attribués à des utilisateurs ou à des groupes. Les utilisateurs peuvent avoir plusieurs rôles, et leurs droits d’accès correspondent à l’union de ces rôles.
- Autorisations : les actions précises qu’un rôle permet d’effectuer (par exemple, envoyer des requêtes aux modèles, lire des fichiers, écrire des fichiers ou gérer des clés).
Autorisations
Le tableau ci-dessous présente les autorisations disponibles, les rôles prédéfinis qui les incluent et la possibilité de les configurer pour des rôles personnalisés.
| Domaine | Actions autorisées | Autorisations du propriétaire de l’organisation | Autorisations du lecteur de l’organisation | Autorisations du propriétaire du projet | Autorisations du membre du projet | Autorisations de l’observateur du projet | Disponible pour les rôles personnalisés |
|---|---|---|---|---|---|---|---|
| Lister les modèles | Lister les modèles auxquels cette organisation a accès | Read | Read | Read | Read | Read | ✓ |
| Groupes | Consulter et gérer les groupes | Read, Write | Read | Read, Write | Read, Write | Read | |
| Rôles | Consulter et gérer les rôles | Read, Write | Read | Read, Write | Read, Write | Read | |
| Administration de l’organisation | Gérer les utilisateurs, les projets, les invitations, les clés d’API d’administration et les limites de débit de l’organisation | Read, Write | |||||
| Utilisation | Consulter le tableau de bord d’utilisation et exporter les données | Read | ✓ | ||||
| Clés externes | Consulter et gérer les clés pour Enterprise Key Management | Read, Write | |||||
| Liste d’adresses IP autorisées | Consulter et gérer la liste d’adresses IP autorisées | Read, Write | |||||
| mTLS | Consulter et gérer les paramètres de TLS mutuel | Read, Write | |||||
| OIDC | Consulter et gérer la configuration OIDC | Read, Write | |||||
| Capacités des modèles | Envoyer des requêtes aux points de terminaison de complétion de discussion, d’audio, de plongements vectoriels et d’images | Request | Request | Request | Request | ✓ | |
| Assistants | Créer et récupérer des Assistants | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Fils de discussion | Créer et récupérer des fils de discussion, des messages et des exécutions | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Évaluations | Créer, récupérer et supprimer des évaluations | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Affinage | Créer et récupérer des tâches d’affinage | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Fichiers | Créer et récupérer des fichiers | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Magasins vectoriels | Créer et récupérer des magasins vectoriels | Read, Write | Read, Write | Read, Write | Read, Write | ✓ | |
| API Responses | Créer des réponses | Read, Write | Read, Write | Read, Write | Read, Write | ✓ | |
| Prompts | Créer et récupérer des prompts à utiliser comme contexte pour l’API Responses et Realtime API | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Webhooks | Créer et consulter des webhooks dans votre projet | Read, Write | Read | Read, Write | Read, Write | Read | ✓ |
| Jeux de données | Créer et récupérer des jeux de données | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Applications | Créer, gérer et soumettre des applications à révision dans le tableau de bord | Read, Write | ✓ | ||||
| Tunnels | Inspecter, utiliser et gérer les tunnels à l’échelle de l’organisation | Read, Use, Manage | ✓ | ||||
| Clés API du projet | Autorisation permettant à un utilisateur de gérer ses propres clés API | Read, Write | Read, Write | Read, Write | Read, Write | Read | ✓ |
| Administration du projet | Gérer les utilisateurs, les comptes de service, les clés API et les limites de débit du projet via l’API de gestion | Read, Write | Read, Write | ||||
| Traitement par lots | Créer et gérer des tâches de traitement par lots | Read, Write | Read, Write | Read, Write | Read, Write | Read | |
| Comptes de service | Afficher et gérer les comptes de service du projet | Read, Write | Read, Write | ||||
| Vidéos | Créer et récupérer des vidéos | Read, Write | Read, Write | Read, Write | Read, Write | ||
| Voix | Créer et récupérer des voix | Read, Write | Read, Write | Read, Write | Read, Write | Read | |
| Agent Builder | Créer et gérer des agents et des workflows dans Agent Builder | Read, Write | Read | Read, Write | Read, Write | Read | ✓ |
Implications des autorisations de traitement par lots
Les autorisations de traitement par lots incluent les accès nécessaires pour préparer les fichiers d’entrée des lots, exécuter les requêtes et récupérer les résultats. Ces accès effectifs sont distincts des points de terminaison auxquels les requêtes soumises dans un lot peuvent faire appel, dont la liste figure dans le guide de l’API Batch.
| Autorisation de traitement par lots | Accès supplémentaires accordés |
|---|---|
Lecture (api.batch.read) | Lecture des fichiers (api.files.read) pour /v1/files |
Écriture (api.batch.write) | Lecture des lots Liste des modèles ( api.model.read et model.read) pour /v1/modelsLecture et écriture des fichiers ( api.files.read et api.files.write) pour /v1/filesRequêtes aux capacités des modèles ( api.model.request et model.request) pour /v1/audio, /v1/chat/completions, /v1/embeddings, /v1/images, /v1/moderations, /v1/realtime et /v1/responsesLecture et écriture des vidéos ( api.videos.read et api.videos.write) pour /v1/videos |
Configuration du RBAC
Prévoyez jusqu’à 30 minutes pour la propagation des modifications de rôles et de la synchronisation des groupes.
-
Créez des groupes Ajoutez des groupes pour les équipes (par exemple, « Science des données » ou « Assistance »). Si vous utilisez un fournisseur d’identité (IdP), activez la synchronisation SCIM pour maintenir à jour l’appartenance aux groupes.
-
Créez des rôles personnalisés Partez du principe du moindre privilège. Par exemple :
- Testeur de modèles : Lecture des modèles, Requêtes aux capacités des modèles, Évaluations
- Ingénieur modèles : Requêtes aux capacités des modèles, Lecture/écriture des fichiers, Affinage
- Éditeur d’applications : Lecture des applications, Écriture des applications
-
Attribuez des rôles
- Les rôles au niveau de l’organisation s’appliquent partout (à tous les projets de l’organisation).
- Les rôles au niveau du projet s’appliquent uniquement à ce projet. Vous pouvez attribuer des rôles aux utilisateurs et aux groupes. Un utilisateur peut avoir plusieurs rôles ; ses droits d’accès correspondent à leur union.
-
Vérifiez Utilisez un compte sans rôle de propriétaire pour confirmer que les accès correspondent à vos attentes (API et tableau de bord). Ajustez les rôles si les utilisateurs peuvent consulter plus d’éléments que nécessaire.
Appliquez le principe du moindre privilège. Commencez par les autorisations minimales nécessaires à une tâche, puis ajoutez-en uniquement selon les besoins.
Exemples de configuration des accès
Petite équipe
- Attribuez à l’équipe principale un rôle au niveau de l’organisation avec les autorisations de requête aux capacités des modèles et de lecture/écriture des fichiers.
- Créez un projet pour chaque application ; ajoutez les prestataires uniquement à ces projets, avec des rôles au niveau du projet.
Organisation de plus grande taille
- Synchronisez les groupes depuis votre fournisseur d’identité (IdP), par exemple « Recherche », « Assistance » et « Finance ».
- Créez des rôles personnalisés par fonction et attribuez-les au niveau de l’organisation ; lorsqu’un projet nécessite des contrôles plus stricts, attribuez uniquement des rôles propres à ce projet.
Prestataires et fournisseurs
- Créez un groupe « Prestataires » sans rôle au niveau de l’organisation.
- Ajoutez-les à des projets précis avec des rôles de projet aux autorisations restreintes (par exemple, un accès en lecture seule).
Comment les accès des utilisateurs sont évalués
Dans le tableau de bord, nous combinons :
- les rôles de l’ organisation (attribués directement + via les groupes)
- les rôles du projet (attribués directement + via les groupes)
Les autorisations effectives sont l’ union de tous les rôles attribués.
Lorsqu’une requête utilise une clé API au sein d’un projet, nous prenons les autorisations attribuées à cette clé et vérifions que l’utilisateur possède un rôle de projet qui lui accorde ces autorisations. Par exemple, pour une requête à /v1/models, la clé API doit disposer de l’autorisation api.model.read et l’utilisateur doit avoir un rôle de projet incluant api.model.read.
Bonnes pratiques
- Représentez votre organisation par des groupes : reproduisez vos équipes dans votre fournisseur d’identité et attribuez les rôles aux groupes, pas aux individus.
- Séparez les responsabilités : distinguez la lecture des modèles, l’envoi de fichiers et la gestion des clés.
- Cloisonnez les projets : placez les expérimentations, la préproduction et la production dans des projets distincts.
- Vérifiez régulièrement : supprimez les rôles et les clés inutilisés ; renouvelez les clés sensibles.
- Testez avec un compte sans rôle de propriétaire : vérifiez que les accès correspondent à vos attentes avant un déploiement à grande échelle.