Résumé

  • id-token: write permet à un job ou workflow GitHub Actions de demander un JWT OIDC ; GitHub précise que ce réglage ne donne pas le droit d’écrire dans des ressources externes.
  • Le fournisseur cloud applique séparément ses conditions de confiance puis peut échanger le JWT contre un jeton d’accès temporaire. La décision de la ressource est encore une autre surface de contrôle.
  • Une affirmation d’autorisation cloud doit joindre la révision du workflow et les claims bornés, la politique de confiance, l’échange et la session, le contexte de permission effective, la décision de ressource et une observation datée de la cible.

Dire qu’un pipeline « a accès au cloud par OIDC » peut décrire une architecture utile. Cette formule devient trop large lorsqu’elle transforme plusieurs décisions indépendantes en une seule conclusion. GitHub peut émettre un jeton d’identité pour un job autorisé à le demander. Le fournisseur peut avoir configuré une confiance envers l’émetteur GitHub et vérifier certains claims. Un échange réussi peut produire un accès temporaire pour ce job. La ressource cloud peut ensuite examiner ce jeton au regard d’un rôle, d’une stratégie de ressource, d’une limite de session, d’un contexte de requête ou d’un refus explicite.

Les acteurs, les moments et les preuves ne sont pas les mêmes.

GitHub fixe la première limite : id-token: write autorise la demande et l’emploi d’un JWT OIDC, non l’écriture vers d’autres ressources. Voir cette permission dans un fichier de workflow établit seulement l’éligibilité à demander un jeton. Cela ne montre ni qu’une demande a eu lieu, ni quelle audience a été choisie, ni quels claims ont été reçus, ni qu’un fournisseur les a acceptés. Le jeton lui-même ne remplace pas le relevé de la politique qui devait l’évaluer.

La confiance cloud est donc un fait séparé. La documentation GitHub explique que le fournisseur valide les claims puis, en cas de succès, fournit un jeton d’accès disponible pour le job. Une condition peut correspondre à un sujet, une audience, une identité de dépôt ou une référence de workflow réutilisable. Un JWT correct peut être refusé par une condition. Une condition peut être plus large ou plus étroite qu’un auteur de release ne le pense. Même après un échange accepté, une stratégie de rôle, une limite de permission, une stratégie d’organisation ou une stratégie de ressource peut interdire l’action concrète.

Le cas AWS rend la séparation visible : GitHub décrit une relation de confiance AWS à configurer et recommande d’évaluer le claim sub dans la stratégie de confiance d’un rôle. Un sub émis par GitHub n’est pas un enregistrement de session AWS. Une session AWS n’est pas non plus l’inventaire de chaque permission effective au moment d’un appel. De la même façon, un job_workflow_ref d’un workflow réutilisable ne prouve pas que le fournisseur pouvait ou devait l’utiliser comme condition. La prise en charge des claims personnalisés varie.

Daniel Kade recommande un reçu en sept parties : révision, déclencheur, job et permission OIDC ; demande et claims bornés, sans révéler un jeton vivant ; révision de l’identité fédérée et de la stratégie de confiance ; échange et identité de rôle ou session ; contexte de permissions effectives ; décision de la ressource et trace de requête ; enfin observation distincte et horodatée de la cible. Les identifiants sensibles peuvent rester protégés. Les jonctions manquantes ne doivent pas être remplacées par le seul mot « fédération ».

Sources

  1. GitHub Docs — Configuring OpenID Connect in cloud providers
  2. GitHub Docs — OpenID Connect reference
  3. GitHub Docs — Configuring OpenID Connect in Amazon Web Services
  4. GitHub Docs — Using OpenID Connect with reusable workflows