Commencez par extraire le véritable token OIDC et vérifiez son champ sub, puis adaptez la règle de confiance cloud : ne revenez pas directement à une clé longue durée. Cette méthode s’applique lorsque GitHub Actions échange un jeton auprès d’un service compatible, tandis que la signature Apple doit rester sur un Mac de publication isolé.

Cette semaine, vous pouvez avancer dans cet ordre : relever les déclarations iss, aud, sub, repository_id et owner_id, comparer la règle cloud actuelle, inventorier les dépôts concernés, puis valider les branches, les environnements et le Runner Mac avant toute remise en production.

Dernière mise à jour : 11 septembre 2026. Les dates, formats de subject et limites de périmètre sont vérifiés à partir de la documentation officielle OIDC de GitHub, de son API REST OIDC et des documents Apple cités dans l’article.

01

Qui doit utiliser cette méthode de correction OIDC ?

Ce guide s’adresse aux équipes plateforme et IT qui administrent GitHub Actions OIDC, les rôles cloud et les règles de confiance. Il concerne aussi les responsables de la performance de développement qui maintiennent un self-hosted runner, Xcode et la chaîne de publication.

Il est également utile avant un renommage, un transfert de dépôt ou l’application d’un modèle OIDC à l’échelle de l’organisation. Les équipes audio, vidéo ou design qui publient des applications iOS depuis un Mac partagé doivent traiter la signature comme une zone de confiance distincte, même lorsque le reste du pipeline utilise des jetons temporaires.

Un échec après une modification apparemment anodine ne signifie donc pas forcément que le fichier de workflow est incorrect. La déclaration reçue par le fournisseur cloud peut avoir changé alors que le dépôt n’a subi aucune modification locale.

02

Le premier indicateur : le format réel du subject

Pourquoi GitHub Actions OIDC peut-il cesser de se connecter au cloud sans changement du workflow ?

La cause la plus rapide à confirmer est une différence entre le sub présent dans le token et le sujet accepté par le fournisseur cloud. À partir du 15 juillet 2026, les dépôts créés après cette date utilisent par défaut un format de subject immuable qui inclut l’identifiant du propriétaire et celui du dépôt. Les anciens dépôts conservent leur format, sauf activation volontaire de cette option. Un renommage ou un transfert peut également entraîner le passage au format immuable, selon l’état du dépôt et de son organisation. Ces règles sont décrites dans la référence OIDC de GitHub.

Ne déduisez pas la valeur à partir du nom du dépôt. Demandez un token depuis un dépôt de test désensibilisé, puis contrôlez ses déclarations. La procédure doit conserver la différence entre le token GitHub et le jeton temporaire remis ensuite par le fournisseur cloud.

Les champs à relever sont les suivants :

  • iss : l’émetteur du token, qui permet de confirmer que la requête vient du fournisseur attendu ;
  • aud : l’audience demandée, souvent utilisée par la règle de confiance pour empêcher une réutilisation dans un autre service ;
  • sub : l’identité précise du dépôt, de la branche, de l’environnement ou du workflow selon le contexte ;
  • repository_id : l’identifiant stable du dépôt, particulièrement important lorsqu’un nom change ;
  • owner_id : l’identifiant stable de l’organisation ou du propriétaire ;
  • les informations de branche, d’environnement ou de workflow lorsqu’elles sont présentes dans le sujet.

L’API REST OIDC de GitHub sert à compléter l’analyse documentaire, mais elle ne remplace pas l’observation du token effectivement émis dans votre contexte. Vous devez conserver l’horodatage, le dépôt de test et le résultat de la tentative, sans exposer de rôle cloud, de compte interne ou d’identifiant de ressource.

Comparer les trois familles de déclaration

Utilisez la comparaison suivante comme outil de décision. Elle ne sert pas à recopier une chaîne de caractères supposée ; elle indique quelle hypothèse vérifier dans le token.

Déclaration observée Ce que cela indique Action prioritaire
Ancien sujet fondé sur le nom du dépôt ou ses éléments de contexte Le dépôt utilise encore l’ancien format, ou l’organisation n’a pas activé l’immuabilité Vérifier que la règle cloud correspond exactement à ce format
Sujet contenant owner_id et repository_id Le dépôt utilise le format immuable décrit par GitHub Adapter la confiance cloud avec les identifiants réellement observés
Sujet généré par un modèle personnalisé L’organisation ou le dépôt applique une personnalisation Comparer le modèle actif et la règle du fournisseur, puis tester chaque environnement

Cette comparaison permet de séparer une panne de déclaration d’un problème d’audience, de permission ou de disponibilité du fournisseur. Elle évite surtout le correctif dangereux consistant à remplacer toute la condition sub par un caractère générique.

03

Deuxième indicateur : la correspondance de la confiance cloud

La correction se trouve souvent dans le fournisseur cloud ou dans la passerelle interne, pas dans le fichier YAML. Une règle peut vérifier le sub complet, seulement la branche, un environnement, une audience ou l’identité d’un workflow réutilisable. Si vous modifiez uniquement le workflow alors que la règle distante attend l’ancien sujet, l’échange restera refusé.

Le cas d’un dépôt renommé ou transféré

Après un renommage, comparez quatre éléments avant de modifier une règle :

  1. le sub du token avant le changement, si un journal désensibilisé est disponible ;
  2. le sub actuel produit par le dépôt ;
  3. la valeur attendue dans le rôle cloud ou la passerelle ;
  4. la présence d’une contrainte sur aud, l’environnement, la branche ou le workflow réutilisable.

Un nom lisible est pratique pour l’équipe, mais il ne constitue pas nécessairement une identité stable. Les identifiants de propriétaire et de dépôt peuvent donc devenir des critères plus robustes lorsque le fournisseur les accepte. Cette décision doit rester compatible avec la documentation de votre service cloud ; ne généralisez pas une syntaxe GitHub à un moteur de confiance qui ne la prend pas en charge.

Pour un dépôt transféré, vérifiez aussi la nouvelle organisation, ses modèles OIDC et ses administrateurs. Une règle liée à l’ancien propriétaire peut échouer même si le code, le workflow et les secrets n’ont pas changé.

Attention : élargir la règle à tous les dépôts de l’organisation peut rétablir une connexion, mais crée une nouvelle frontière de confiance. Le dépannage n’est réussi que si le dépôt attendu est accepté et qu’une source non autorisée reste refusée.

Les preuves à conserver

Un ticket de correction exploitable doit contenir :

  • le journal d’échec du workflow ;
  • le token ou ses déclarations désensibilisées ;
  • la version de la règle de confiance ;
  • le dépôt, l’environnement et la branche de test ;
  • le résultat d’une tentative autorisée et d’une tentative refusée ;
  • la condition de retour arrière.

Ne copiez pas les jetons complets dans un outil de discussion ou un système de tickets. Même un token de courte durée reste une donnée d’authentification pendant sa période de validité.

04

Troisième indicateur : l’étendue du changement organisationnel

Un dépôt créé après le 15 juillet 2026 peut adopter par défaut le subject immuable. Un ancien dépôt peut l’activer volontairement. Un administrateur peut aussi appliquer un modèle d’organisation. Ces trois situations ne produisent pas le même périmètre de migration.

Avant de changer un modèle, établissez une liste des dépôts, environnements et rôles qui en dépendent. Classez-les selon le niveau de risque :

  • dépôts de test sans accès à une ressource sensible ;
  • dépôts de développement ayant accès à des environnements partagés ;
  • dépôts de préproduction ;
  • dépôts de publication iOS ou macOS ;
  • workflows réutilisables appelés par plusieurs équipes.

Cette cartographie révèle les dépendances invisibles. Un modèle modifié au niveau de l’organisation peut affecter un dépôt qui n’a jamais été identifié comme consommateur direct d’OIDC. Un rôle cloud partagé peut également servir plusieurs pipelines, avec des règles dont la maintenance n’est attribuée à aucune équipe.

La règle de décision

Si le token présente un nouveau sub et que la confiance cloud attend l’ancien format, modifiez d’abord la règle distante, puis testez un seul dépôt pilote. Si le sub est correct mais que l’audience ou l’environnement ne correspond pas, ne touchez pas au format du subject : corrigez uniquement le critère concerné.

Si aucune déclaration ne correspond à la documentation du fournisseur, suspendez la migration. Examinez le modèle actif, le périmètre du produit et la possibilité que votre installation soit GitHub Enterprise Server. La capacité décrite pour GitHub.com ne doit pas être extrapolée automatiquement à toutes les éditions.

05

Quatrième indicateur : les permissions du workflow

Le job qui demande un token doit obtenir explicitement la permission id-token: write. Cette permission n’implique pas un accès général à votre cloud : elle autorise la demande du jeton OIDC, qui doit ensuite être accepté par une règle de confiance. Toutefois, donner cette permission à tous les jobs augmente la surface d’analyse et complique l’audit.

Conservez les permissions au niveau du job lorsque seul un segment du pipeline doit accéder à une ressource externe. Maintenez aussi les restrictions sur contents, les environnements protégés, les approbations et les branches. Une correction OIDC qui supprime ces garde-fous n’est pas une correction de production.

Évaluez chaque rôle selon quatre questions :

  • Quels sujets sont autorisés ?
  • Quels sujets sont explicitement refusés ?
  • Quelle est la portée du jeton temporaire obtenu auprès du cloud ?
  • Quelle approbation est requise avant l’accès à l’environnement sensible ?

Les GitHub Secrets ne sont pas équivalents à un token OIDC. Un secret statique peut rester nécessaire pour un service qui ne prend pas en charge la fédération, mais il doit alors avoir une rotation, une portée et une procédure de révocation documentées. Ne remplacez pas une panne OIDC par une clé cloud longue durée simplement parce que le résultat est plus rapide à obtenir.

06

Cinquième indicateur : séparer le cloud, le Runner Mac et la signature Apple

GitHub Actions OIDC peut fournir une identité fédérée à un service compatible. Il ne transforme pas cette identité en certificat de signature Apple. Il ne remplace pas non plus une clé privée d’API App Store Connect.

Apple documente la création de clés pour l’API App Store Connect et distingue cette authentification des certificats utilisés pour signer les applications. Les certificats gérés dans le cloud sont présentés séparément dans la documentation des certificats cloud d’Apple. Vous devez donc conserver une séparation explicite entre :

  • le token OIDC émis pour le workflow ;
  • le jeton temporaire reçu d’un fournisseur cloud ;
  • les GitHub Secrets ;
  • la clé privée utilisée par l’API App Store Connect ;
  • le certificat et le trousseau nécessaires à la signature Apple.

Cette distinction est décisive sur un Mac distant. Un job provenant d’une demande de fusion non fiable ne doit pas pouvoir atteindre le trousseau de publication simplement parce qu’il peut obtenir un rôle cloud. Les accès aux ressources cloud, la construction Xcode et la signature de production doivent appartenir à des niveaux différents.

Comparer les trois modèles de Mac de publication

Mac partagé sur le long terme

  • Avantage : gestion centralisée et coûts d’exploitation prévisibles.
  • Limite : résidus de workspace, trousseaux persistants et mélange des jobs si le nettoyage est incomplet.
  • Usage acceptable : compilation non sensible ou publication avec isolation logicielle réellement vérifiée.

Runner éphémère

  • Avantage : environnement recréé pour réduire les résidus entre deux tâches.
  • Limite : préparation plus complexe, gestion des certificats et récupération après interruption.
  • Usage acceptable : jobs de test et de compilation lorsque la signature est externalisée ou strictement contrôlée.

Mac dédié à la publication

  • Avantage : frontière claire pour le trousseau, les approbations et la traçabilité.
  • Limite : capacité moins flexible et dépendance à un nœud spécifique.
  • Usage acceptable : version finale, distribution interne ou publication App Store.

La documentation de sécurité des self-hosted runners de GitHub rappelle que ces machines doivent être traitées comme des environnements sensibles. Un Runner qui exécute du code non fiable ne doit pas partager automatiquement le même contexte de confiance qu’un nœud de signature.

Pour un essai contrôlé, vous pouvez isoler un Mac distant dédié au build et mesurer séparément l’accès cloud, le nettoyage du workspace, la rotation des secrets et le verrouillage du trousseau. Les configurations de Mac distant proposées par VpsMesh peuvent servir de point de départ pour cette étude, sans confondre un nœud de test avec une autorisation de publication permanente.

07

Sixième indicateur : l’audit et la reprise après correction

La remise en service doit produire des résultats vérifiables, pas seulement un workflow vert. Utilisez un dépôt de test et contrôlez au minimum :

  • une branche autorisée ;
  • une branche non autorisée ;
  • un environnement approuvé ;
  • un environnement sans approbation ;
  • un workflow réutilisable autorisé ;
  • un workflow réutilisable hors périmètre ;
  • un échange OIDC réussi ;
  • un accès cloud refusé lorsque le sub ou aud ne correspond pas.

Pour un self-hosted runner, ajoutez les contrôles propres au Mac : redémarrage du Runner, réaffectation d’une tâche, nettoyage du workspace, absence de trousseau dans un job non autorisé et prise en charge par un nœud de secours. Les résultats doivent être associés à la version du modèle OIDC et à celle de la règle cloud.

La procédure de retour arrière doit préciser ce qui est restauré. Revenir à l’ancien format n’est pas toujours possible ni souhaitable pour les dépôts déjà passés au subject immuable. Un retour arrière sûr peut plutôt consister à désactiver temporairement un déploiement, à maintenir une branche de publication approuvée et à rétablir la règle précédente uniquement après vérification de la déclaration réellement émise.

Si vous devez tester une nouvelle organisation de publication, comparez aussi les options de location Mac de VpsMesh avec votre nœud partagé actuel. Le critère principal n’est pas seulement la puissance de compilation : c’est la possibilité de séparer le Runner, l’espace de travail, le trousseau et les preuves d’audit.

08

Ce que votre architecture actuelle risque de masquer

Une architecture qui place OIDC, les secrets cloud et la signature Apple sur la même machine simplifie le premier déploiement, mais elle augmente le rayon d’impact d’un job compromis. Un Mac partagé conserve potentiellement des fichiers temporaires, un trousseau accessible et des journaux produits par plusieurs équipes. Une règle cloud élargie peut ensuite donner à d’autres dépôts une capacité qui n’était pas prévue.

La location d’un Mac distant ne corrige pas automatiquement ces défauts. Elle devient intéressante lorsque vous l’utilisez comme nœud dédié, avec routage explicite, nettoyage vérifiable, accès SSH ou VNC limité et séparation du Mac de build par rapport au Mac de signature. Pour une validation régionale ou un pilote, vous pouvez également comparer un nœud Mac mini distant à Singapour à votre infrastructure actuelle, sans transférer les clés de production avant l’acceptation des contrôles.

Une fois la règle OIDC réparée, examinez donc la cohabitation réelle entre identité cloud, identité du Runner et identité Apple. Si votre nœud actuel ne permet pas de les isoler, un Mac distant dédié peut servir à tester la publication, la récupération après panne et la rotation des credentials avant une extension à toute l’entreprise.