Installare una GitHub App nell’enterprise non apre il codice dei repository

Dev
Visualizzazioni 4

Uno script aziendale può dipendere dal token personale di un collega che non lavora più lì. Il 23 ottobre GitHub ha annunciato la disponibilità generale delle installazioni enterprise per GitHub Apps. Più attività amministrative possono abbandonare i PAT classici, ma installare nell’enterprise non concede accesso a tutto il codice.

Cosa gestisce l’app enterprise

Le novità includono policy dei repository, ruleset, lettura delle richieste di bypass e liste di IP consentiti. Leggere una richiesta e modificare la regola sono operazioni con permessi diversi. Non serve attivare ogni diritto di scrittura per iniziare.

L’installazione enterprise concede solo permessi enterprise. Anche se la registrazione richiede permessi di organizzazione e repository, questi non vengono concessi qui. Leggere il codice di due organizzazioni richiede installazioni separate e gli accessi appropriati. Poter vedere le impostazioni ma non il codice può quindi essere il risultato corretto.

Una app, più installazioni

Immaginiamo l’enterprise acme con le organizzazioni web e mobile. Installando la stessa app nei tre account si ottengono tre installazioni. Il token enterprise non sostituisce quello di web; quello di web non vale per mobile. Il disegno originale illustra un esempio fittizio, non un’interfaccia reale.

Diagramma originale: installazioni enterprise, web e mobile separate; le linee indicano i confini degli account. Fonte: GitHub Docs, 25 ottobre 2026.
Diagramma originale: installazioni enterprise, web e mobile separate; le linee indicano i confini degli account. Fonte: GitHub Docs, 25 ottobre 2026.

Una cache non dovrebbe quindi usare solo il nome dell’app come chiave. L’ID di installazione aiuta a separare i processi per le policy enterprise da quelli che leggono repository. È un esempio di implementazione del confine di account documentato.

Dove si incontrano i permessi di app e utente

Un token utente dipende dai permessi sia dell’app sia dell’utente. Se l’utente può solo leggere, l’app non può superare quel limite agendo per suo conto. Un token di installazione segue invece i permessi assegnati all’app in quella installazione.

Per generarlo servono il JWT dell’app e l’ID dell’installazione. La documentazione descrive POST /app/installations/INSTALLATION_ID/access_tokens e una validità di un’ora. Octokit può gestire generazione e rinnovo. Restano necessari la protezione della chiave privata e una cache distinta per installazione.

Diagramma originale di emissione tramite JWT e ID di installazione, con scadenza e permessi. Nessun token reale né richiesta di autenticazione.
Diagramma originale di emissione tramite JWT e ID di installazione, con scadenza e permessi. Nessun token reale né richiesta di autenticazione.

Prima di sostituire il token personale

Se uno script combina policy enterprise e codice di varie organizzazioni, cambiare una stringa può non bastare. Occorre separare le attività, verificare il supporto delle API e scegliere l’autenticazione adatta. Non tutte le operazioni GraphQL enterprise supportano le app. Partire da una lettura rende più semplice confrontare i risultati.

Le fonti hanno tempi diversi: il changelog del 23 ottobre annuncia disponibilità generale, mentre la pagina di installazione consultata oggi mantiene la dicitura public preview. Qui lo stato segue l’annuncio datato e l’ambito dei permessi la documentazione. Il vantaggio è definire l’automazione per account e compito, senza copiare tutta l’autorità di una persona.

Fonti e approfondimenti

GitHub Changelog · 2026-10-23

GitHub Docs · Enterprise installation

GitHub Docs · Permissions

GitHub Docs · Enterprise GraphQL

GitHub Docs · Installation token