Fédération d’identité de charge de travail

La fédération d’identité de charge de travail permet à une tâche automatisée d’appeler l’API sans stocker de clé d’API. La tâche a déjà un jeton d’identité fourni par sa plateforme : une exécution GitHub Actions, un compte de service Google Cloud ou un compte de service Kubernetes. Elle nous envoie ce jeton et reçoit en retour un jeton valide au plus 15 minutes qui fonctionne comme une de vos clés d’inférence.

Étape 1 : Choisir la clé utilisée

Créez une clé d’inférence pour cette charge de travail dans Clés, avec une limite de dépenses adaptée. Une clé dédiée rend ses dépenses faciles à suivre et à arrêter. Vous ne copiez jamais cette clé : la politique ne fait que la désigner.

Étape 2 : Ajouter une politique

Dans Paramètres → Fédération d’identité de charge de travail, choisissez Ajouter une politique et remplissez :

• URL de l’émetteur : qui signe les jetons de la charge de travail. Ce doit être une URL https publique qui publie /.well-known/openid-configuration.
• Sujet (sub) : la revendication sub exacte que le jeton doit porter. C’est elle qui limite la politique à un dépôt, une branche ou un compte de service.
• Audience visée (aud) : l’audience exacte pour laquelle la charge de travail demande son jeton. Choisissez une valeur qui n’appartient qu’à vous, comme autonomousrelay.
• Clé d’API utilisée : la clé de l’étape 1.
• Vérifications de revendications supplémentaires (facultatif) : une ligne revendication=valeur par vérification. Chacune doit correspondre au jeton; pour une revendication de type liste, la liste doit contenir la valeur.

Enregistrez-la et copiez son ID de la politique; la charge de travail l’envoie à chaque échange.

Étape 3 : Obtenir un jeton de votre plateforme

GitHub Actions

• URL de l’émetteur : https://token.actions.githubusercontent.com
• Sujet : repo:OWNER/REPO:ref:refs/heads/BRANCH pour une branche, ou repo:OWNER/REPO:environment:NAME pour un environnement de déploiement.
• Vérification supplémentaire (recommandée) : repository_owner=OWNER.
• Le flux de travail a besoin de permissions: id-token: write. Il demande son jeton avec l’audience choisie :

SUBJECT_TOKEN=$(curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
  "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=autonomousrelay" | jq -r .value)

Google Cloud

• URL de l’émetteur : https://accounts.google.com
• Sujet : l’ID unique du compte de service (le long nombre sur sa page de détails), pas son adresse courriel.
• Sur Compute Engine, Cloud Run ou GKE, lisez le jeton depuis le serveur de métadonnées :

SUBJECT_TOKEN=$(curl -sS -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=autonomousrelay")

Kubernetes

• URL de l’émetteur : l’émetteur des comptes de service de votre grappe. Il doit être joignable publiquement en https, comme sur EKS et GKE.
• Sujet : system:serviceaccount:NAMESPACE:NAME.
• Montez un jeton de compte de service projeté avec votre audience (serviceAccountToken.audience: autonomousrelay) et lisez-le depuis le fichier.

Autres plateformes

Tout émetteur convient si ses jetons sont des JWT signés en RS256 (clés RSA de 2048 bits ou plus) ou en ES256, et s’il publie ses clés par la découverte OpenID Connect.

Étape 4 : L’échanger

Envoyez le jeton de la plateforme et l’ID de votre politique à l’URL d’échange de jetons :

curl -sS -X POST https://autonomousrelay.com/v1/oauth/token \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d subject_token_type=urn:ietf:params:oauth:token-type:jwt \
  -d subject_token="$SUBJECT_TOKEN" \
  -d federation_policy_id=YOUR_POLICY_ID

{
  "access_token": "eyJ...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "inference"
}

Utilisez access_token exactement comme une clé d’API, en Authorization: Bearersur tout appel d’inférence. Il ne dure jamais plus longtemps que le jeton de la plateforme. Refaites l’échange à son expiration; il n’y a pas de jeton d’actualisation. Nos clés publiques de signature sont à https://autonomousrelay.com/v1/oauth/jwks.

Mise en pause et suppression

Mettre en pause ou Supprimer la politique arrête immédiatement les nouveaux échanges. Les jetons déjà émis fonctionnent jusqu’à leur expiration, au plus 15 minutes. Pour les arrêter aussi, mettez en pause ou révoquez la clé utilisée par la politique.

Dépannage

Un échange refusé répond 400 avec invalid_grant et une description (en anglais) :

• « No active federation policy has that id » : l’ID de la politique est erroné, ou la politique est en pause ou supprimée.
• « The key this policy acts as is no longer active » : la clé a été révoquée ou a expiré. Associez la politique à une autre clé.
• Un message sur iss, sub ou aud : la revendication du jeton ne correspond pas exactement à la politique. Décodez le jeton (sa partie centrale est du JSON en base64) et comparez.
• Un message sur la signature : le jeton n’a pas été signé par une des clés publiées de l’émetteur, ou utilise un type de clé non accepté.
• « Could not read the issuer’s … » : nous n’avons pas pu joindre le document de découverte ou les clés de l’émetteur. Vérifiez l’URL de l’émetteur.
• 503 temporarily_unavailable : l’échange de jetons n’est pas encore activé sur ce déploiement.