Installer une GitHub App sur une entreprise ne donne pas accès au code
Un script de configuration peut rester lié au jeton personnel d’un collègue parti. Le 23 octobre, GitHub a annoncé la disponibilité générale des installations d’entreprise pour GitHub Apps. Davantage de tâches administratives peuvent abandonner les PAT classiques. Mais une installation au niveau entreprise ne donne pas accès à tout le code.
Ce que gère l’application d’entreprise
L’annonce couvre notamment les politiques de dépôt, les rulesets, la lecture des demandes de dérogation et les listes d’adresses IP autorisées. Lire une demande et modifier une règle nécessitent des droits différents. Il est inutile d’activer toutes les permissions d’écriture pour commencer.
L’installation d’entreprise ne confère que des permissions d’entreprise. Les permissions d’organisation et de dépôt demandées par l’application ne sont pas accordées par cette installation. Lire le code de deux organisations exige des installations distinctes avec les accès appropriés. Un refus de lecture du code alors que les paramètres d’entreprise restent accessibles peut donc être normal.
Une application, plusieurs installations
Prenons l’entreprise fictive acme et ses organisations web et mobile. La même application installée sur ces trois comptes possède trois installations. Le jeton d’entreprise ne remplace pas celui de web ; celui de web ne fonctionne pas pour mobile. Notre schéma explique cet exemple, sans reproduire une interface ou un compte réel.
Une cache de jetons ne devrait donc pas utiliser uniquement le nom de l’application comme clé. Ajouter l’identifiant d’installation permet de séparer les tâches de politique d’entreprise et de lecture du code. C’est une proposition d’implémentation du périmètre de compte décrit par la documentation.
Permissions de l’application et de l’utilisateur
Un jeton utilisateur dépend des permissions de l’application et de celles de l’utilisateur. Si ce dernier ne dispose que de la lecture, l’application ne peut pas dépasser ce droit en agissant en son nom. Le jeton d’installation dépend des permissions accordées à l’application dans cette installation.
La génération utilise le JWT de l’application et l’identifiant d’installation. La documentation décrit POST /app/installations/INSTALLATION_ID/access_tokens et une durée d’une heure. Octokit peut générer et renouveler ces jetons. Il faut toujours protéger la clé privée et distinguer les installations dans la cache.
Avant de remplacer le jeton personnel
Un script mêlant politiques d’entreprise et code de plusieurs organisations peut exiger davantage qu’un remplacement de chaîne. Il faut séparer les tâches, vérifier la compatibilité des API et choisir le mode d’authentification adapté. Toutes les opérations GraphQL d’entreprise ne prennent pas en charge les applications. Commencer par une lecture facilite la comparaison.
Les sources présentent un décalage : l’annonce du 23 octobre indique une disponibilité générale, mais la documentation d’installation consultée aujourd’hui mentionne encore la préversion publique. Le statut retenu vient de l’annonce datée, les périmètres viennent de la documentation. L’intérêt est de définir l’automatisation par compte et par tâche plutôt que de recopier les pouvoirs étendus d’une personne.
Sources et lectures complémentaires
GitHub Docs · Enterprise installation