Suivez ce guide pour créer un projet OpenAI et mettre en place des contrôles d’accès réutilisables. Vous définirez les actions autorisées pour les identités à l’aide d’un rôle de projet, réunirez ces identités dans un groupe de l’organisation et associerez ce groupe au projet.
À l’issue du workflow principal, vous disposerez d’une configuration reproductible qui :
- Crée un projet OpenAI pour une application.
- Définit un rôle de projet respectant le principe du moindre privilège.
- Crée un groupe au sein de l’organisation pour les identités qui ont besoin d’un accès.
- Accorde au groupe l’accès au projet par l’intermédiaire du rôle.
- Ajoute au groupe un utilisateur existant de l’organisation.
Avant de commencer
Effectuez la configuration du fournisseur Terraform et exportez une clé de l’API d’administration dans OPENAI_ADMIN_KEY. Vous aurez également besoin de l’ID d’un utilisateur existant de l’organisation et des identifiants des autorisations approuvées pour l’application. Utilisez une organisation de test pour évaluer le workflow.
La destruction d’une ressource openai_project archive le projet au lieu de le supprimer définitivement. Vous ne pouvez pas restaurer un projet archivé.
Créez le périmètre du projet
Créez un projet pour l’application :
resource "openai_project" "application" {
name = "example-application-development"
}Le projet délimite le périmètre de l’utilisation de l’API, des comptes de service, des limites de débit, des alertes de dépenses et des paramètres de projet de l’application. Terraform rend l’ID généré accessible via openai_project.application.project_id. Les ressources du projet peuvent faire référence à cette valeur ; Terraform crée donc le projet avant ces ressources.
Cet exemple ciblé utilise un nom concret. L’exemple complet présenté plus loin le remplace par une variable pour vous permettre de réutiliser la configuration dans différents environnements.
Définissez les autorisations du projet
Créez un rôle de projet avec les autorisations approuvées pour l’application :
resource "openai_project_role" "application" {
project_id = openai_project.application.project_id
role_name = "Application API access"
description = "Permissions approved for this application"
permissions = ["api.webhooks.read"]
}La ressource openai_project_role définit les actions qu’une identité peut effectuer dans le projet. Cet exemple accorde l’autorisation de lire la configuration des webhooks. Remplacez api.webhooks.read par les identifiants des autorisations approuvées pour votre application et commencez par les seules autorisations dont elle a besoin.
La modification de permissions met à jour le rôle. Exécutez terraform plan pour examiner chaque autorisation ajoutée ou supprimée avant d’appliquer la modification.
Créez ou réutilisez un groupe
Créez un groupe au sein de l’organisation lorsque Terraform doit en gérer le cycle de vie :
resource "openai_group" "application_access" {
name = "example-application-development-access"
}Les groupes existent au niveau de l’organisation et peuvent être réutilisés dans plusieurs projets. Un nom se terminant par -access indique que l’appartenance au groupe accorde un accès, plutôt que de simplement décrire une équipe.
Si un autre système gère un groupe existant, lisez plutôt ses données :
data "openai_group" "application_access" {
group_id = "group_123"
}La source de données lit les informations du groupe sans confier la gestion de son cycle de vie à cette configuration. Vous pouvez lire les groupes gérés par SCIM, mais effectuez les changements d’appartenance dans le système d’identité qui les gère.
Accordez au groupe l’accès au projet
Associez le groupe au rôle personnalisé dans le projet :
resource "openai_project_group_role" "application_access" {
project_id = openai_project.application.project_id
group_id = openai_group.application_access.group_id
role_id = openai_project_role.application.role_id
}Cet exemple utilise le groupe géré par Terraform. Si vous avez réutilisé un groupe existant via la source de données, remplacez l’expression group_id par data.openai_group.application_access.group_id.
L’attribution relie trois objets :
project_ididentifie le projet auquel le groupe obtient accès.group_ididentifie l’ensemble d’identités qui obtient l’accès.role_ididentifie les autorisations accordées au groupe.
Les membres du groupe héritent du rôle personnalisé dans ce projet. L’ajout d’un rôle ou d’un groupe ne suffit pas à accorder un accès ; l’attribution établit le lien entre les deux.
Ajoutez des utilisateurs et d’autres identités
Ajoutez une identité à un groupe de l’organisation géré par Terraform avec openai_group_user :
resource "openai_group_user" "application_developer" {
group_id = openai_group.application_access.group_id
user_id = "user_123"
}user_id peut identifier un utilisateur ou un compte de service existant de l’organisation. Pour ajouter un compte de service, utilisez openai_project_service_account.application.id comme valeur de user_id. Consultez Comptes de service pour connaître les exigences relatives à l’accès des comptes de service par groupe, à l’authentification et au cycle de vie des identifiants d’authentification.
Utilisez des attributions de rôles directes lorsque l’accès par groupe n’est pas adapté :
resource "openai_project_user_role" "application_developer" {
project_id = openai_project.application.project_id
user_id = "user_123"
role_id = openai_project_role.application.role_id
}Pour les autorisations à l’échelle de l’organisation, créez un rôle d’organisation et attribuez-le directement ou par l’intermédiaire d’un groupe :
variable "organization_role_permissions" {
type = list(string)
}
resource "openai_role" "platform_operator" {
role_name = "Platform operator"
description = "Organization permissions for the platform team"
permissions = var.organization_role_permissions
}
resource "openai_user_role" "platform_operator" {
user_id = "user_123"
role_id = openai_role.platform_operator.role_id
}Définissez organization_role_permissions sur les identifiants des autorisations approuvées au niveau de l’organisation. Séparez les autorisations de l’organisation de celles du projet afin que chaque attribution ait la portée minimale nécessaire.
Examinez les attributions actuelles
Consultez les rôles d’organisation et de projet attribués à une identité avant de modifier ses accès :
data "openai_user_roles" "current" {
user_id = "user_123"
}
data "openai_project_user_roles" "current" {
project_id = openai_project.application.project_id
user_id = "user_123"
}
output "organization_roles" {
value = data.openai_user_roles.current.roles
}
output "project_roles" {
value = data.openai_project_user_roles.current.roles
}Les sources de données indiquent les attributions actuelles, mais n’en confient pas la gestion à Terraform.
Supprimez des attributions
Lorsque Terraform gère déjà une attribution, la suppression de son bloc de ressource conduit le prochain plan à proposer la suppression de l’attribution distante. Examinez le plan et vérifiez qu’une autre voie accorde toujours les accès nécessaires.
Pour une attribution préexistante, déclarez d’abord la ressource correspondante et importez-la à l’aide de l’ID composite documenté. Vérifiez que le premier plan ne prévoit aucune modification avant de retirer la ressource de la configuration et d’appliquer la suppression.
Terraform ne peut supprimer que les attributions enregistrées dans son état. Pour supprimer une attribution par défaut existante, importez-la d’abord dans la ressource Terraform correspondante. Retirez ensuite cette ressource de votre configuration et appliquez le plan de destruction qui en résulte. Si votre organisation n’autorise pas ce workflow d’importation puis de destruction, supprimez l’attribution selon une procédure approuvée, via le tableau de bord ou l’API d’administration.
Consultez Importation et réconciliation pour connaître les formats d’importation et les étapes à suivre pour une prise en charge sûre des ressources existantes.
Exécutez l’exemple complet
Les exemples ciblés utilisent des valeurs concrètes pour illustrer clairement chaque relation. La configuration complète remplace les valeurs répétées propres à chaque environnement par des variables, afin que vous puissiez la réutiliser sans modifier les définitions des ressources.
Enregistrez la configuration suivante dans main.tf :
terraform {
required_version = ">= 1.0"
required_providers {
openai = {
source = "openai/openai"
version = ">= 1.0.0"
}
}
}
provider "openai" {}
variable "project_name" {
type = string
}
variable "project_role_permissions" {
type = list(string)
}
variable "user_id" {
type = string
}
resource "openai_project" "application" {
name = var.project_name
}
resource "openai_project_role" "application" {
project_id = openai_project.application.project_id
role_name = "Application API access"
description = "Permissions approved for this application"
permissions = var.project_role_permissions
}
resource "openai_group" "application_access" {
name = "${var.project_name}-access"
}
resource "openai_project_group_role" "application_access" {
project_id = openai_project.application.project_id
group_id = openai_group.application_access.group_id
role_id = openai_project_role.application.role_id
}
resource "openai_group_user" "application_developer" {
group_id = openai_group.application_access.group_id
user_id = var.user_id
}
output "project_id" {
value = openai_project.application.project_id
}
output "group_id" {
value = openai_group.application_access.group_id
}
output "project_role_id" {
value = openai_project_role.application.role_id
}Créez terraform.tfvars avec un nom de projet unique, l’ID d’un utilisateur existant de l’organisation et les autorisations approuvées :
project_name = "example-application-development"
user_id = "user_123"
project_role_permissions = [
"api.webhooks.read",
]Initialisez Terraform, puis examinez et appliquez un plan enregistré :
terraform init
terraform fmt
terraform validate
terraform plan -out=tfplan
terraform show tfplan
terraform apply tfplanLe premier plan devrait prévoir l’ajout de cinq ressources. Après son application, l’utilisateur hérite du rôle de projet personnalisé par l’intermédiaire du groupe, et terraform output affiche les ID du projet, du groupe et du rôle de projet. Exécutez à nouveau terraform plan pour vérifier que la configuration ne produit plus aucune modification.
Pour ajouter d’autres utilisateurs humains, reprenez le modèle d’appartenance au groupe en utilisant un nom de ressource Terraform unique pour chaque utilisateur. Pour configurer une identité non humaine, consultez Comptes de service. Suivez les guides Contrôles des modèles, des outils et des données et Limites de débit et dépenses pour ajouter des garde-fous au projet.