Référence des règles de fédération de Codex

Une règle de fédération détermine quelles identités de charges de travail vérifiées peuvent agir au nom d’un même utilisateur ou compte de service ChatGPT. OpenAI évalue uniquement la règle que le processus Codex désigne. Il ne parcourt pas toutes les règles à la recherche d’une correspondance.

Chaque règle cible un seul principal et peut accepter une ou plusieurs identités en amont. Pour accepter plusieurs sujets dans une même règle, utilisez un préfixe de sujet suivi d’un caractère générique ou une condition CEL. Vous pouvez aussi créer plusieurs règles pour un même principal.

Structure d’une règle

Avant l’échange, le principal doit déjà exister et être membre de l’espace de travail. Lorsqu’une charge de travail se connecte, la règle ne crée aucun utilisateur ni compte de service et n’ajoute aucun membre à l’espace de travail.

Combinaison des contrôles d’identité

Une règle peut utiliser les contrôles suivants :

Configurez au moins un contrôle portant sur le sujet, la valeur exacte d’un attribut ou une condition CEL. Une audience acceptée ne suffit pas à identifier une charge de travail. Si vous configurez plusieurs types de contrôles, tous doivent réussir.

OpenAI effectue d’abord les vérifications définies pour le fournisseur. Une règle ne peut contourner aucun de ces contrôles, qu’ils portent sur l’émetteur, la signature, l’expiration, la durée de vie de l’assertion, le rejeu ou une condition CEL du fournisseur.

Correspondance du sujet

Utilisez un sujet exact lorsqu’une valeur stable de sub suffit à identifier la charge de travail :

repo:example-company/payments:environment:production

Un seul * en fin de chaîne permet une correspondance par préfixe :

system:serviceaccount:production:codex-*

Le caractère générique doit être le dernier caractère et suivre un préfixe non vide. OpenAI n’accepte ni *, ni repo:*:production, ni repo/*/main.

Évitez les préfixes trop larges lorsqu’un attribut plus stable permet de distinguer les charges de travail privilégiées. Par exemple, pour GitHub, limitez la règle à un dépôt, à un fichier de workflow, à une référence Git ou à un environnement protégé plutôt que d’accepter tous les dépôts d’une organisation.

Correspondance exacte des attributs

Ce contrôle compare les attributs de premier niveau du JWT sans convertir leur type. Une chaîne ne correspond qu’à une chaîne identique, un booléen qu’au même booléen et un nombre qu’à la même valeur numérique. Ce contrôle n’accepte pas les listes ni les objets comme valeurs exactes.

Par exemple :

12345{
  "repository": "example-company/payments",
  "ref": "refs/heads/main",
  "environment": "production"
}

N’incluez pas sub dans la table des attributs à comparer par valeur exacte. Utilisez le champ du sujet ou une condition CEL. Utilisez CEL pour vérifier les attributs imbriqués du fournisseur ou l’appartenance à une liste.

Conditions CEL

Les conditions CEL reçoivent la table complète des attributs vérifiés du JWT sous le nom assertion et doivent renvoyer true ou false. OpenAI prend en charge un sous-ensemble limité de CEL pour que l’évaluation des règles reste prévisible.

Pour autoriser plusieurs sujets exacts dans une même règle :

assertion.sub in [
  "repo:example-company/payments:environment:production",
  "repo:example-company/billing:environment:production"
]

Pour exiger un dépôt précis et l’une de deux références Git :

assertion.repository == "example-company/payments" &&
assertion.ref in ["refs/heads/main", "refs/heads/release"]

Pour lire un attribut imbriqué ou facultatif :

has(assertion.environment) &&
assertion.environment == "production"

Les opérations disponibles comprennent has, size, contains, startsWith et endsWith. OpenAI ne prend pas en charge les recherches par expression régulière, les macros de parcours de collections telles que all ou exists, les fonctions arbitraires ni les identifiants autres que assertion. Utilisez des expressions courtes et privilégiez les contrôles de correspondance exacte lorsqu’ils permettent d’exprimer la même politique.

OpenAI refuse l’échange si un attribut est absent, si une opération n’est pas prise en charge, si le résultat n’est pas booléen ou si l’évaluation échoue.

Correspondance de l’audience

Le fournisseur peut définir une seule audience attendue. Une règle peut définir à la place une ou plusieurs audiences acceptées. Si la règle contient une liste d’audiences, au moins une valeur de l’attribut aud du jeton doit figurer dans cette liste.

Utilisez une audience dédiée à OpenAI si votre fournisseur le permet. Les règles SPIFFE JWT-SVID doivent définir une audience acceptée. Une règle OIDC doit également en définir une si le fournisseur ne définit aucune audience à son niveau.

Le contrôle de l’audience et les contrôles d’identité se cumulent. Même si l’audience correspond, OpenAI refuse l’échange si le contrôle du sujet, la correspondance exacte d’un attribut ou la condition CEL échoue.

Nombre de principaux par règle

Chaque règle correspond à un seul principal :

many accepted external identities -> one federation rule -> one OpenAI principal

Des réplicas de charges de travail, des tâches ou des sujets approuvés peuvent ainsi agir au nom du même utilisateur ou compte de service. Une règle ne peut pas sélectionner un principal différent selon les attributs. Créez des règles distinctes lorsque les charges de travail nécessitent des principaux, des espaces de travail, des portées ou des durées de vie de jeton différents.

Plusieurs règles peuvent cibler le même principal. Utilisez des règles distinctes pour gérer le cycle de vie de chacune indépendamment ou pour identifier plus clairement la charge de travail à l’origine de chaque action lors d’un audit.

Portées et autorisation

La règle peut restreindre les portées OAuth du jeton d’accès émis. Elle ne peut pas accorder de permissions dont le principal cible ou l’espace de travail ne dispose pas déjà.

Si vous ne précisez aucune portée, OpenAI utilise les portées standard de Codex : openid, profile, email et l’accès local à Codex. Si vous définissez les portées via l’API d’administration, incluez chatgpt.workspace.feature.allow-codex-local-access.access et utilisez uniquement ces quatre valeurs prises en charge.

Appliquez d’abord le principe du moindre privilège au choix du principal et des permissions de l’espace de travail. Utilisez les portées de la règle comme restriction supplémentaire. Le principal et les permissions de l’espace de travail restent la base du contrôle d’accès.

Durée de vie du jeton

Fixez la durée de vie du jeton d’accès OpenAI entre 60 et 3 600 secondes. OpenAI retient la plus courte des deux durées suivantes :

• La durée de vie restante du jeton d’identité en amont.
• La durée de vie du jeton d’accès configurée dans la règle.

Une durée de vie plus courte réduit le temps pendant lequel un jeton déjà émis peut rester valide après une modification de la politique, mais impose des échanges plus fréquents. Une durée de 10 minutes constitue un bon point de départ, sauf si votre charge de travail nécessite un autre compromis.

Protection contre le rejeu

La protection contre le rejeu au niveau du fournisseur s’appuie sur l’attribut jti du JWT. Si un administrateur active Empêcher le rejeu des assertions et que le jeton contient un jti non vide, OpenAI n’accepte ce jti qu’une seule fois pour ce fournisseur jusqu’à l’expiration de l’assertion.

Avant chaque échange, la charge de travail doit obtenir une nouvelle assertion avec un nouveau jti, y compris avant de réessayer un échange dont le résultat est inconnu. Les assertions sans jti restent utilisables, mais ne bénéficient pas de la protection contre le rejeu. La validation échoue si la valeur de jti est vide, nulle ou d’un type autre qu’une chaîne.

Modification, désactivation et archivage

Les modifications courantes des contrôles d’identité, des portées ou de la durée de vie des jetons s’appliquent aux nouveaux échanges. Les jetons d’accès émis avant la modification peuvent rester valides jusqu’à leur expiration initialement prévue.

La désactivation d’une règle ou d’un fournisseur bloque les nouveaux échanges et révoque les jetons d’accès OpenAI émis via cette règle ou ce fournisseur. L’archivage a les mêmes effets et est irréversible. Si vous modifiez les paramètres de confiance du fournisseur, par exemple l’émetteur ou les paramètres JWKS, OpenAI révoque les jetons déjà émis avant l’entrée en vigueur de la nouvelle configuration.

Désactivez la ressource pour un arrêt d’urgence ou une suspension temporaire. Archivez-la uniquement lorsque vous n’en avez plus besoin.

Limites

Créez des fournisseurs distincts pour les périmètres de confiance qui nécessitent une gestion indépendante des émetteurs, des clés, de la protection contre le rejeu ou du cycle de vie. Au sein d’un même fournisseur, créez des règles distinctes pour les charges de travail qui partagent le même périmètre de confiance, mais nécessitent des principaux ou des politiques d’accès différents.