Fédération des identités de charges de travail

La fédération des identités de charges de travail permet aux automatisations de confiance d’utiliser Codex sans stocker de jeton d’accès personnel ni d’autre identifiant OpenAI à longue durée de vie. Votre charge de travail présente un jeton d’identité à courte durée de vie provenant d’un fournisseur que vous exploitez déjà. OpenAI vérifie ce jeton et renvoie un jeton d’accès à courte durée de vie pour un utilisateur ou un compte de service de votre espace de travail ChatGPT géré.

Utilisez une identité de charge de travail pour les processus Codex sans surveillance sur les plateformes cloud, Kubernetes, les systèmes CI et les autres environnements capables d’émettre des jetons OIDC ou des SPIFFE JWT-SVIDs. Pour consulter le modèle de confiance partagé et le flux OpenAI API distinct, reportez-vous à la présentation des identités de charges de travail.

Avant de commencer

Vous avez besoin des éléments suivants :

• L’autorisation de gérer les identités de charges de travail dans l’OpenAI Admin Portal.
• Un espace de travail ChatGPT géré.
• Un utilisateur ou compte de service ChatGPT qui est membre actif de cet espace de travail, ou l’autorisation d’en créer un pendant la configuration.
• Un jeton OIDC ou un SPIFFE JWT-SVID dont vous connaissez l’émetteur, l’audience et les revendications d’identification.
• Un environnement d’exécution capable de maintenir ce jeton à jour dans un fichier protégé situé à un chemin absolu.
• Codex 0.148.0 ou version ultérieure.
• Une politique d’authentification Codex effective qui autorise l’authentification ChatGPT et l’espace de travail sélectionné par la règle de fédération. Consultez Imposer une méthode de connexion ou un espace de travail.

OpenAI ne crée ni principal ni appartenance à un espace de travail pendant l’échange de jetons. Un administrateur sélectionne ou crée le principal avant que la charge de travail ne se connecte. La création d’un utilisateur humain consomme une licence de l’espace de travail et respecte les règles d’adhésion de cet espace de travail.

Sous Windows natif, utilisez le bac à sable Windows elevated. Les autres modes de bac à sable Windows ne peuvent pas protéger le fichier du jeton d’identité contre les commandes contrôlées par le modèle.

Obtenir un jeton d’identité

L’environnement d’exécution de votre charge de travail obtient et actualise le jeton d’identité en amont. Codex n’appelle pas les services de métadonnées cloud ni les bibliothèques clientes du fournisseur d’identité à votre place.

Suivez le guide de votre fournisseur pour configurer l’émission de jetons et inspecter un exemple de jeton :

• Microsoft Azure
• AWS
• Google Cloud
• Oracle Cloud Infrastructure
• GitHub Actions
• Kubernetes
• SPIFFE

Décodez localement un exemple de jeton et consignez ses iss, aud, sub ainsi que toute autre revendication à laquelle vous prévoyez de faire confiance. Le décodage ne vérifie pas la signature. Ne collez pas de jeton de production dans un site Web et ne l’écrivez pas dans les journaux.

Connecter la charge de travail

Un administrateur crée le fournisseur et la règle de fédération avant de démarrer Codex.

1. Ouvrez Identité de charge de travail dans l’OpenAI Admin Portal, puis sélectionnez Connect workload.
2. Réutilisez un fournisseur configuré pour Codex ou créez-en un. Les préréglages de fournisseur renseignent les paramètres courants pour GitHub Actions, Microsoft Entra ID, Google Cloud, AWS, Kubernetes, SPIFFE et les fournisseurs OIDC personnalisés.
3. Sélectionnez Codex et l’espace de travail géré que la charge de travail est autorisée à utiliser.
4. Ajoutez les conditions les plus restrictives permettant d’identifier la charge de travail. Faites correspondre un sujet, des revendications exactes, une condition CEL ou une combinaison de ces éléments. Ajoutez les audiences acceptées afin de limiter les jetons acceptés par la règle. Tous les critères configurés doivent être satisfaits.
5. Associez la règle à un utilisateur ou compte de service ChatGPT existant, ou créez-en un pendant la configuration.
6. Vérifiez le fournisseur, les conditions, l’espace de travail, le principal, les portées et la durée de vie du jeton d’accès. Sélectionnez Connect workload, puis Download config.

Le fichier téléchargé contient un ID de règle de fédération non secret et le chemin où Codex lira le jeton d’identité. Il ne contient aucun identifiant.

Pour automatiser la configuration, utilisez l’API Admin des identités de charges de travail. Pour en savoir plus sur le comportement des critères de correspondance et consulter des exemples, reportez-vous à la référence des règles de fédération.

Configurer le processus Codex

Le processus qui démarre Codex nécessite ces deux variables d’identité de charge de travail :

export OPENAI_FEDERATION_RULE_ID="idpm_..."
export OPENAI_IDENTITY_TOKEN_FILE="/var/run/secrets/openai.com/identity-token"

OPENAI_FEDERATION_RULE_ID n’est pas un secret. Le fichier de jeton, lui, l’est. Utilisez un chemin absolu dans un répertoire dédié, tel que /var/run/secrets/openai.com, appartenant au compte de la charge de travail avec le mode 0700. Seuls les processus hôtes de confiance doivent pouvoir y écrire. Conservez le répertoire en dehors des dépôts et des autres chemins accessibles aux outils Codex. Ne placez aucun identifiant dans les journaux, l’historique du shell ou les artefacts de build.

Ajouter une attribution d’audit

Lorsque plusieurs instances d’exécution partagent une règle de fédération, vous pouvez identifier chaque instance dans les événements d’audit d’émission de jetons. Définissez la variable facultative OPENAI_WORKLOAD_IDENTITY_CONTEXT sur un objet JSON encodé sous forme de chaîne :

export OPENAI_WORKLOAD_IDENTITY_CONTEXT='{
  "instance_id": "runner-42",
  "display_name": "payments-prod",
  "labels": {
    "environment": "production",
    "region": "us-west-2"
  }
}'

L’objet exige instance_id. Il peut également contenir display_name et jusqu’à huit libellés. L’objet encodé peut avoir une taille maximale de 1 024 octets. instance_id et display_name peuvent comporter jusqu’à 128 caractères. Les clés de libellé peuvent comporter jusqu’à 64 caractères et les valeurs de libellé jusqu’à 256 caractères.

Les identifiants doivent commencer par une lettre ou un chiffre ASCII. Les valeurs peuvent ensuite contenir des lettres, des chiffres, ., _, :, /, @ et -. Les clés de libellé prennent en charge les lettres, les chiffres, ., _ et -.

OpenAI considère ce contexte comme une attribution d’audit déclarée par le client, et non comme une identité de charge de travail vérifiée. Il n’affecte ni l’authentification, ni l’autorisation, ni la correspondance des règles, ni les portées, ni les limites de débit, ni la révocation, ni les fonctionnalités conditionnelles, ni les métriques. N’y placez pas d’identifiants, de secrets, de données personnelles, d’invites, de sorties du modèle ou d’autres Customer Content.

Pour un contexte valide, OpenAI dérive un ID d’attribution stable limité au locataire, au fournisseur, à la règle de fédération et à instance_id. Aux fins d’attribution, le jeton d’accès contient l’ID, mais pas le contexte. L’événement d’audit d’émission de jeton réussie contient l’ID et le contexte normalisé. Un contexte qui dépasse une limite ou enfreint ce schéma provoque l’échec de l’échange avec invalid_grant.

Codex lit le contexte au démarrage du processus et ne le transmet pas, pas plus que l’ID de la règle ou le chemin du fichier de jeton, aux shells, hooks ou serveurs MCP contrôlés par le modèle. Redémarrez Codex après avoir modifié le contexte.

Protéger le fichier de jeton et assurer sa rotation

Pour les déploiements Linux gérés, macOS et WSL, ajoutez l’intégralité du répertoire du jeton à permissions.filesystem.deny_read dans les exigences gérées :

[permissions.filesystem]
deny_read = ["/var/run/secrets/openai.com"]

Cela empêche les commandes contrôlées par le modèle de lire le jeton actif ou un fichier de remplacement temporaire, tandis que le processus hôte Codex peut toujours utiliser le jeton pour l’échange. Pour les volumes de jetons projetés, refusez l’accès à l’intégralité du point de montage du jeton ainsi qu’à tous les chemins sous-jacents ou cibles résolus situés en dehors de celui-ci. Les modes de fichier et la suppression des variables d’environnement ne suffisent pas à protéger les identifiants contre un autre processus exécuté sous le même utilisateur. Sous Windows natif, utilisez le bac à sable elevated décrit ci-dessus.

Pour les sources de jetons qui ne projettent pas de fichier, demandez à un processus hôte de confiance d’écrire chaque fichier de remplacement dans ce répertoire protégé, puis de le renommer à son emplacement définitif. Un renommage atomique empêche Codex de lire un jeton partiel. Par exemple, adaptez ce script d’actualisation appartenant à l’hôte à la commande de jeton de votre fournisseur. Provisionnez le répertoire avant d’exécuter le script :

set -eu
TOKEN_DIR="/var/run/secrets/openai.com"
TOKEN_FILE="$TOKEN_DIR/identity-token"
umask 077
TOKEN_TEMP="$(mktemp "$TOKEN_DIR/.identity-token.XXXXXX")"
trap 'rm -f -- "$TOKEN_TEMP"' EXIT
trap 'exit 1' HUP INT TERM
your-identity-provider-command > "$TOKEN_TEMP"
test -s "$TOKEN_TEMP"
mv -f -- "$TOKEN_TEMP" "$TOKEN_FILE"

Exécutez le processus d’actualisation en dehors de tout shell ou outil que Codex peut contrôler. Maintenez le refus d’accès en lecture pendant l’actualisation et le nettoyage. Même si un arrêt forcé laisse un fichier temporaire, celui-ci doit rester dans le répertoire interdit. Ne placez pas les paramètres d’identité de charge de travail dans config.toml.

Vérifier la connexion

Chargez l’environnement téléchargé et inspectez la méthode d’authentification sélectionnée :

. ./workload-identity-idpm_example.env
codex login status

Dans PowerShell :

$env:OPENAI_FEDERATION_RULE_ID = "idpm_..."
$env:OPENAI_IDENTITY_TOKEN_FILE = "C:\run\openai\identity-token"
codex login status

En cas de réussite, la vérification affiche Logged in using workload identity. Cela confirme que Codex a échangé un jeton par l’intermédiaire de la règle de fédération configurée. La commande n’affiche ni l’espace de travail résolu, ni le principal, ni la règle. Confirmez ces valeurs dans l’Admin Portal avant de démarrer la charge de travail. Si Codex signale une autre méthode d’authentification, les deux variables WIF requises ne sont pas parvenues au processus.

Si le fournisseur utilise Prevent assertion replay et que l’assertion possède une revendication jti, cette vérification consomme ce jti. Écrivez une assertion nouvellement émise avec un nouveau jti avant de démarrer un autre processus Codex.

Exécutez une petite requête depuis le même environnement :

codex exec "Reply with only: workload identity is working"

Codex échange le jeton en amont et conserve le jeton d’accès OpenAI en mémoire. Il n’écrit aucun des deux identifiants dans auth.json, le trousseau système ou config.toml.

Maintenir le jeton à jour

Actualisez le fichier du jeton d’identité avant l’expiration du jeton en amont. Codex relit le fichier lorsqu’il a besoin d’un autre jeton d’accès OpenAI. Le jeton OpenAI expire à la première des deux échéances suivantes : l’expiration du jeton en amont ou la durée de vie de la règle de fédération ; il ne reste jamais valide plus d’une heure.

Lorsqu’un administrateur active la protection contre la relecture, chaque JWT en amont doit avoir un jti unique. Écrivez une assertion nouvellement émise avec un nouveau jti avant chaque échange, y compris lors des actualisations dans un processus de longue durée. Les assertions dépourvues de jti ne bénéficient pas de la protection contre la relecture.

Codex partage une seule session d’échange en mémoire au sein de chaque processus hôte. Les requêtes simultanées de ce processus réutilisent un jeton d’accès OpenAI valide et partagent une seule actualisation à son expiration. Les processus distincts effectuent des échanges distincts et nécessitent donc des assertions que le fournisseur les autorise à utiliser.

Priorité des identifiants

Les deux variables d’identité de charge de travail requises sont prioritaires sur toutes les autres sources d’identifiants :

1. Si OPENAI_FEDERATION_RULE_ID ou OPENAI_IDENTITY_TOKEN_FILE est présent, Codex sélectionne l’identité de charge de travail.
2. Si une seule des variables requises est présente, Codex renvoie une erreur. Il ne se rabat pas sur une API key, un jeton d’accès ou une connexion enregistrée.
3. OPENAI_WORKLOAD_IDENTITY_CONTEXT seul ne sélectionne pas l’identité de charge de travail.
4. Lorsqu’aucune des variables WIF requises n’est présente, Codex applique les règles habituelles relatives aux identifiants pour cette surface. Pour les surfaces qui autorisent l’authentification par API key, CODEX_API_KEY est prioritaire sur codex exec, codex review, le TypeScript SDK et codex exec-server --remote. Les autres surfaces peuvent utiliser CODEX_ACCESS_TOKEN ou une connexion enregistrée.

Une option SDK apiKey devient CODEX_API_KEY, mais WIF reste prioritaire lorsque l’une des variables WIF requises est présente. Omettez l’option lorsque vous utilisez WIF afin que la charge de travail ne transporte pas un identifiant à longue durée de vie inutilisé.

Pour migrer une charge de travail existante sans interruption, configurez WIF tant que son identifiant actuel est toujours disponible. Démarrez un nouveau processus avec les deux variables WIF requises ; WIF est prioritaire même si l’ancien identifiant est encore présent. Une fois que la charge de travail fonctionne avec WIF, supprimez l’ancien identifiant de son environnement d’exécution et de son magasin de secrets, puis révoquez-le. Avant la révocation, vous pouvez revenir en arrière en supprimant les deux variables WIF requises et en démarrant un nouveau processus.

Surfaces Codex prises en charge

Configurez l’identité de charge de travail sur la machine qui héberge le processus Codex.

Les clients app-server et exec-server distants n’envoient jamais le jeton d’identité en amont par l’intermédiaire de leurs protocoles.

Modifier ou supprimer l’accès

Les modifications apportées aux sujets, audiences, revendications, à la condition CEL, aux portées ou à la durée de vie du jeton d’une règle s’appliquent aux nouveaux échanges. Un jeton émis avant la modification peut rester valide jusqu’à la fin de sa durée de vie.

Désactivez un fournisseur ou une règle pour interrompre immédiatement l’accès. La désactivation bloque les nouveaux échanges et révoque les jetons d’accès OpenAI déjà émis via cette ressource. L’archivage produit le même effet sur l’accès et ne peut pas être annulé. La modification de la confiance du fournisseur révoque également les jetons émis avant l’entrée en vigueur de la nouvelle confiance.

Auditer les modifications

La création, la mise à jour et l’archivage des fournisseurs et des règles de fédération génèrent des événements d’audit. Utilisez l’API Compliance et les recommandations relatives aux événements d’audit pour exporter les événements pris en charge par votre espace de travail. Mettez-les en corrélation avec les journaux d’émission de votre fournisseur d’identité et n’enregistrez les assertions en amont ou les jetons d’accès OpenAI dans aucun de ces systèmes.

Lorsque le processus fournit OPENAI_WORKLOAD_IDENTITY_CONTEXT, les événements d’audit d’émission de jeton réussie contiennent également l’ID d’attribution stable et le contexte normalisé décrits ci-dessus.

Résoudre les problèmes

Pour en savoir plus sur la vérification des fournisseurs, les limites et CEL, consultez la référence des règles de fédération.