Une clé API est un identifiant secret qui permet d’authentifier les requêtes. Un compte de service est une identité non humaine qu’une application ou une charge de travail automatisée peut utiliser. Un compte de service peut détenir des clés API. Le compte fournit alors l’identité et la clé permet d’authentifier les requêtes de ce compte.
Pour vos propres travaux de développement, utilisez une clé de projet rattachée à votre compte utilisateur. Pour une application ou une automatisation qui doit disposer de ses propres autorisations et suivre son propre cycle de vie, utilisez un compte de service. Pour gérer votre organisation via les API d’administration, utilisez une clé API d’administration.
Choisissez l’identité adaptée
| Charge de travail | Identité et identifiant | Pourquoi ce choix ? |
|---|---|---|
| Vos propres travaux de développement ou d’exploration en local | Votre compte utilisateur et une clé API de projet | Vos requêtes utilisent vos droits d’accès au projet. |
| Une application déployée, une tâche planifiée ou un workflow d’intégration continue | Un compte de service de projet et sa clé API | La charge de travail dispose d’une identité distincte de celle d’un développeur. |
| Une charge de travail qui utilise un fournisseur d’identité pris en charge par OpenAI | Un compte de service de projet avec fédération d’identités de charges de travail | La charge de travail peut s’authentifier sans stocker de clé API OpenAI de longue durée. |
| Une automatisation qui crée des projets ou gère leurs comptes de service et leurs clés | Une clé API d’administration | La gestion de l’organisation repose sur des points de terminaison et des autorisations d’administration distincts. |
Les requêtes effectuées avec la clé d’un utilisateur utilisent les droits d’accès de celui-ci. Ne partagez pas la clé d’un développeur au sein d’une équipe et n’utilisez pas son identité comme identité permanente d’une application en production.
Un compte de service appartient à un projet. Attribuez à chaque charge de travail l’identité et les droits d’accès dont elle a besoin dans ce projet. Des projets distincts permettent de séparer les ressources, les membres et l’utilisation de chaque application ou environnement. Au sein d’un même projet, des comptes de service distincts permettent de différencier les charges de travail sans créer de projet supplémentaire.
Comprenez les autorisations et leur portée
Les actions autorisées dépendent à la fois des autorisations de la clé API et de celles de son propriétaire. Vous pouvez limiter les actions possibles en restreignant la portée de la clé, mais vous ne pouvez pas ainsi accorder de droits supplémentaires à l’utilisateur ou au compte de service. Même sans restriction, une clé reste soumise aux autorisations effectives de son propriétaire.
Attribuez au compte de service uniquement les rôles dont sa charge de travail a besoin, puis restreignez la portée de ses clés si nécessaire. Consultez le guide des autorisations et des rôles pour comprendre le modèle d’autorisation. Le guide sur les comptes de service avec Terraform présente une configuration qui crée une identité, lui attribue un rôle personnalisé et génère une clé de portée limitée.
Une clé API d’administration et une clé de projet destinée à une charge de travail ont des usages différents. Conservez la clé d’administration dans le service de confiance qui provisionne et gère les ressources. Pour les requêtes que l’application envoie aux modèles, utilisez l’identifiant du compte de service du projet.
Automatisez la gestion des projets et des clés
Si votre application provisionne des projets pour ses clients, un compte de service de projet donne à chaque charge de travail une identité indépendante du développeur qui exécute le processus de provisionnement. Votre service de provisionnement utilise les API d’administration pour gérer le projet et ses comptes de service. L’application provisionnée utilise son propre identifiant de projet.
Les opérations d’administration à utiliser sont les suivantes :
| Opération | Objectif |
|---|---|
| Créer un projet | Créer le projet auquel appartiennent les ressources et le compte de service de la charge de travail. |
| Créer un compte de service | Créer l’identité de la charge de travail dans ce projet. L’option create_service_account_only crée le compte sans rôle par défaut ni clé API initiale. |
| Créer une clé API de compte de service | Générer une clé pour un compte de service existant, en définissant sa portée et, si nécessaire, une date d’expiration. |
| Gérer les clés API du projet | Lister, récupérer, mettre à jour ou révoquer les clés existantes du projet, y compris celles des comptes de service. |
Les points de terminaison de gestion des clés API de projet ne permettent pas de créer une clé de projet au nom d’un autre utilisateur. Pour créer une clé par programmation, utilisez un compte de service et le point de terminaison de création de clés associé.
Si vous créez un compte de service sans rôle par défaut, il ne dispose pas de l’autorisation d’envoyer des requêtes aux modèles. Attribuez-lui les autorisations requises avant d’utiliser ses identifiants. Les politiques de l’organisation et du projet relatives aux clés s’appliquent également à la création de clés. Un compte de service ne permet pas de les contourner.
Gérez les identifiants tout au long de leur cycle de vie
L’API ne renvoie la valeur complète d’une clé de compte de service qu’au moment où vous la créez. Stockez-la dans votre gestionnaire de secrets et mettez-la à la disposition de la charge de travail côté serveur. N’incluez aucune clé secrète dans le code exécuté par le navigateur, les applications mobiles, les dépôts de code source, les journaux ou les réponses envoyées aux clients.
Fixez une date d’expiration conforme aux politiques de votre organisation et de votre projet. Pour renouveler une clé, générez une clé de remplacement, mettez à jour la charge de travail pour qu’elle utilise la nouvelle clé, vérifiez son bon fonctionnement, puis révoquez l’ancienne clé. Le compte de service peut conserver la même identité lorsque ses clés changent.
Réexaminez les droits d’accès de la charge de travail lorsque ses fonctions changent et révoquez ses identifiants lorsque vous la mettez hors service. Consultez les recommandations sur les clés API en production pour en savoir plus sur la gouvernance des clés et les politiques d’expiration. Pour authentifier une charge de travail sans stocker de clé API, consultez le guide sur la fédération d’identités de charges de travail.