Authentification en amont sans clé pour les passerelles AI API : un modèle de fédération d'identité de charge de travail

Les travailleurs de la passerelle de production ne doivent pas transporter de clés API en amont de longue durée lorsque le fournisseur peut authentifier lui-même la charge de travail. Le modèle le plus sûr consiste à échanger une identité cloud, Kubernetes, CI ou SPIFFE existante contre un identifiant de fournisseur de courte durée, à mettre correctement en cache cet identifiant et à le restreindre à la plus petite limite d'autorisation utile.

La partie difficile n'est pas l'échange de jetons. Il gère la prise en charge inégale des fournisseurs, les actualisations simultanées, le mappage d'identité, les exceptions du plan de contrôle, les pannes et la migration sans créer de repli caché vers une clé partagée largement privilégiée.

Commencez avec des fonctionnalités d'authentification, pas avec un paramètre global sans clé

Fait : La prise en charge de l'authentification diffère selon le fournisseur et l'opération. OpenAI et Anthropic prennent en charge la fédération d'identité de charge de travail pour API charges de travail. Azure OpenAI prend en charge l'ID Microsoft Entra et les identités managées. Google Cloud prend en charge les comptes de service associés, les informations d'identification par défaut de l'application et la fédération d'identité de charge de travail pour les charges de travail externes. Cependant, les API d'inférence d'exécution et d'administration n'acceptent pas nécessairement les mêmes types d'informations d'identification.

Par exemple, OpenAI jetons d'identité de charge de travail ne peuvent actuellement pas appeler les points de terminaison de l'administrateur API. Une passerelle ne peut donc pas représenter en toute sécurité l'authentification comme un champ de niveau fournisseur tel que auth_mode: federated.

Recommandation : Créez une matrice de capacités classée par compte de fournisseur, famille de points de terminaison, environnement et classe d'opération :

Stockez cette matrice en tant que configuration versionnée. L'admission de route doit rejeter une opération lorsque son identité configurée ne peut pas satisfaire la capacité d'authentification requise. Cela appartient à un plan de contrôle IA API pour les équipes de développeurs, et non à des variables d'environnement non documentées sur des travailleurs individuels.

Placez un courtier d'informations d'identification entre les adaptateurs de routage et de fournisseur

Les adaptateurs de fournisseur ne doivent pas récupérer les informations d'identification des métadonnées, construire des assertions ou gérer l'actualisation des jetons de manière indépendante. Présentez un courtier d'informations d'identification avec une interface étroite :

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

La valeur des identifiants est sensible et doit rester en mémoire ou dans un cache éphémère approuvé. Le contexte d'autorisation enregistre le projet du fournisseur, le compte de service, les étendues, les rôles ou les restrictions de déploiement représentés par le jeton. La provenance identifie la manière dont il a été acquis, par exemple oidc_exchange, managed_identity, adc ou break_glass.

Ce contrat reste indépendant du fournisseur de routage tout en préservant les détails nécessaires aux contrôles d'autorisation et à la télémétrie. Cela empêche également une passerelle multimodèle API pour les équipes de traiter chaque jeton de porteur comme interchangeable.

Utiliser des adaptateurs d'acquisition spécifiques au fournisseur

Chaque adaptateur d'acquisition doit effectuer uniquement les étapes requises par son fournisseur :

• Obtenez une assertion externe à partir de la source d'identité locale, telle qu'un jeton de compte de service projeté Kubernetes, un service de métadonnées cloud ou une charge de travail SPIFFE API.
• Demandez l'audience exacte attendue par le fournisseur ou la règle de fédération configurée.
• Échangez l'assertion lorsque le fournisseur nécessite un échange de jetons.
• Renvoyer le résultat délai d'expiration des informations d'identification et des autorités.
• Classer les échecs en tant qu'erreurs d'identité locale, d'échange, d'autorisation, de configuration ou de disponibilité du fournisseur.

Le point de terminaison compatible OpenAI de Vertex AI est un exemple utile de séparation : une application peut obtenir un jeton d'accès Google via les informations d'identification par défaut de l'application et fournir ce jeton comme identifiant du client OpenAI. L'adaptateur de protocole reste compatible avec OpenAI, tandis que l'acquisition des informations d'identification reste spécifique à Google.

Rendre le cache de jetons sensible aux autorisations

Fait : Les identifiants fédérés sont de courte durée. OpenAI jetons d'accès à l'identité de charge de travail ne durent pas plus d'une heure, ne peuvent pas survivre au jeton d'objet externe ou au certificat vérifié, et sont émis sans jetons d'actualisation. La charge de travail doit répéter l'échange avant l'expiration.

Une clé de cache doit inclure toutes les dimensions pouvant modifier l'autorité résultante :

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

L'omission du compte, de l'audience ou des étendues cibles peut amener un travailleur à réutiliser un jeton valide dans un contexte d'autorisation incorrect. C'est plus dangereux qu'un échec de cache.

Actualiser avant expiration en utilisant une marge de sécurité et une gigue aléatoire. Une politique pratique est la suivante :

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

La marge exacte doit tenir compte du décalage d'horloge, de la latence d'échange, du temps de nouvelle tentative et de la requête attendue la plus longue. Ne pas actualiser uniquement sur une minuterie fixe détachée de expires_at.

Prévenez les tempêtes d'échange grâce à l'actualisation d'un seul vol

Lorsque de nombreuses requêtes rencontrent le même jeton proche de l'expiration, une seule exécution doit effectuer l'échange. Les autres appelants doivent continuer à utiliser les informations d'identification existantes tant qu'elles restent dans la fenêtre autorisée, ou attendre brièvement le résultat de l'actualisation partagée.

Utilisez un verrou à vol unique par clé de cache. Dans un déploiement multi-processus ou multi-nœuds, décidez si chaque travailleur peut gérer son propre cache ou si la coordination des actualisations doit être distribuée. Un cache local est plus simple mais augmente le volume des échanges. Un cache distribué réduit les échanges mais élargit la limite des jetons sensibles et nécessite un transport chiffré, un contrôle d'accès strict et une expulsion minutieuse.

Recommandation : Préférez les caches en cours de processus, sauf si les limites du fournisseur ou la taille du parc démontrent la nécessité d'un service de jetons partagés. Coordonnez d'abord les actualisations au sein de chaque processus, puis mesurez le volume d'échange.

Lier les identités aux revendications exactes de la charge de travail

La fédération déplace la confiance d'une clé stockée vers des revendications d'identité. Un mappage permissif peut donc être aussi dangereux qu'une fuite d'informations d'identification partagées.

Validez l'émetteur et le public visé, puis liez le mappage à des revendications immuables ou étroitement contrôlées. Pour Kubernetes, incluez l'espace de noms et le compte de service plutôt que de faire confiance à une charge de travail du cluster. Pour CI, limitez le référentiel, le flux de travail, l'environnement et la branche protégée ou le contexte de déploiement. Pour les identités cloud, mappez un principal de charge de travail spécifique plutôt qu'un locataire ou une organisation dans son intégralité.

Créez des comptes de service en amont distincts ou des identités gérées pour la production, la préparation, les tâches en arrière-plan et l'automatisation administrative. Limitez chaque identité aux modèles, projets, espaces de travail, déploiements et API opérations dont elle a besoin.

Fait : OpenAI peut restreindre les mappages d'identité de charge de travail avec API autorisations. Anthropic associe les informations d'identification échangées à un compte de service et avertit que la fédération est aussi sécurisée que la configuration de l'identité en amont. De la même manière, les identités gérées et l'IAM dans le cloud dépendent d'attributions de rôles correctement définies.

Séparez les identifiants d'exécution des identifiants d'administration

Un travailleur d'inférence ne devrait jamais hériter d'un jeton d'administrateur d'organisation simplement parce qu'une tâche du plan de contrôle en a encore besoin. Divisez le système en deux limites de sécurité :

• Plan d'exécution : Gère les requêtes de modèle et reçoit uniquement les informations d'identification fédérées ou gérées limitées à l'inférence.
• Plan de contrôle : Effectue l'administration de projets, d'espaces de travail, de facturation ou de comptes de service via des tâches isolées avec des informations d'identification stockées séparément et des contrôles d'approbation plus stricts.

Les informations d'identification administratives ne doivent avoir aucun chemin vers les variables d'environnement d'exécution, les spécifications de pod, les bundles de débogage ou les caches de jetons. Enregistrez leur utilisation dans le même système d'audit d'ajout uniquement utilisé pour les modifications de configuration.

Échec fermé sans improvisation de récupération

Recommandation : Ne remplacez pas automatiquement un échange de fédération ayant échoué par une clé statique partagée. Le repli automatique peut contourner un mappage révoqué, masquer une audience incorrecte ou restaurer un accès intentionnellement supprimé par un administrateur d'identité.

Renvoie une erreur d'authentification en amont classifiée, arrête la distribution vers le compte du fournisseur concerné et autorise la politique de routage normale à sélectionner un autre fournisseur uniquement lorsque cette alternative est autorisée pour le locataire et la charge de travail. Le remplacement du modèle et le remplacement des informations d'identification sont des décisions différentes.

Une clé à bris de glace peut toujours être justifiée en cas de pannes graves du fournisseur d'identité. Gardez-le désactivé ou inaccessible en fonctionnement normal. L'activation doit nécessiter une approbation authentifiée, avoir une expiration fixe, restreindre le compte et les opérations du fournisseur concerné et alerter sur chaque demande effectuée avec celui-ci. Sa provenance doit apparaître dans la télémétrie de la requête.

Migrer un pool de routage à la fois

1. Environnement d'exécution de l'inventaire et informations d'identification administratives. Identifiez les processus qui peuvent lire chacun d'entre eux.
2. Créez une identité de charge de travail dédiée et un compte de service fournisseur à portée étroite.
3. Configurez les mappages exacts d'émetteur, d'audience, de sujet et d'autorisation.
4. Ajoutez une vérification préliminaire qui acquiert un jeton et appelle un point de terminaison autorisé à faible impact.
5. Canary un petit pool de routage en utilisant uniquement la fédération. Ne laissez pas le remplacement automatique des clés activé pendant le test.
6. Comparez les échecs d'authentification, la latence d'échange, l'âge du jeton et les résultats d'autorisation du fournisseur avec le chemin existant.
7. Augmentez progressivement le trafic et observez au moins un cycle complet d'actualisation du jeton.
8. Supprimez l'ancienne clé de l'accès à l'exécution, puis révoquez-la après la période d'observation définie.

Répétez ce processus par compte de fournisseur et par environnement. Un basculement global rend difficile la distinction entre une erreur de mappage d'identité et le comportement d'un jeton spécifique au fournisseur.

Instrumenter et tester les modes de défaillance

Enregistrez la latence d'échange de jetons, les tentatives d'actualisation, les échecs d'actualisation, l'âge des informations d'identification, l'émetteur, le principal mappé, le compte du fournisseur, la classe d'opération et la catégorie d'erreur d'authentification. N'enregistrez jamais les jetons d'accès, les assertions externes, les secrets client ou les en-têtes d'autorisation complets.

Avant que la fédération ne devienne la seule voie de production, testez :

• Décalage d'horloge entre les nœuds de calcul, les fournisseurs d'identité et les services de jetons du fournisseur.
• Indisponibilité du serveur de métadonnées ou du point de terminaison d'identité de charge de travail.
• Assertions expirées et audiences incorrectes.
• Suppression de rôle et désactivation des règles de fédération.
• Limitation des échanges de jetons et fournisseur temporaire erreurs.
• Actualisation simultanée en cas de pic de trafic.
• Rotation des clés de signature pendant que les anciens jetons restent valides.

Pour la rotation des émetteurs OIDC, publiez les anciennes et les nouvelles clés de signature avec un chevauchement suffisant pour les caches des vérificateurs et les jetons émis. OpenAI documente une mise en cache de 600 secondes pour la découverte et les données JWKS distantes, avec une actualisation JWKS lorsqu'un jeton fait référence à un ID de clé inconnu. Ne présumez pas que chaque vérificateur se comporte de la même manière ; tester la rotation avec des canaris vivants.

Adopter l'authentification d'exécution sans clé en tant que migration limitée

Le but n'est pas de prétendre que la passerelle ne contient aucun secret. Il s'agit de supprimer les clés de fournisseur de longue durée des travailleurs d'exécution à volume élevé et de limiter les informations d'identification administratives inévitables à une limite plus petite du plan de contrôle.

Commencez par la matrice de capacités, négociez les informations d'identification via une seule interface, mettez en cache par contexte d'autorisation, utilisez des mappages d'identité exacts et fermez en cas d'échec en cas d'erreurs d'échange. Terminez la migration uniquement après avoir observé avec succès les tests d’actualisation, de révocation, de panne et de rotation des clés de signature. Cela produit un chemin d'exécution sans clé dont la disponibilité et le comportement d'autorisation sont compris plutôt que supposés.

Lecture connexe

• vérifier les informations d'identification du fournisseur avant d'acheminer le trafic de production