Quattro scenari, non quattro nomi commerciali
Dire “usiamo GitHub Enterprise” non identifica un ambiente. Esistono quattro scenari di deployment e la differenza fra loro non è di listino ma di architettura: cambia chi possiede gli account, chi ospita il codice, su quale dominio ci si autentica e quali funzionalità sono effettivamente presenti.
Il primo è GitHub Enterprise Cloud (GHEC) con account personali: l’enterprise account raccoglie le organizzazioni, ma le persone accedono con il proprio account personale su github.com, spesso creato prima dell’assunzione e destinato a sopravvivere all’uscita. Il secondo è GHEC con Enterprise Managed Users (EMU): gli account non appartengono più alle persone, li crea l’azienda tramite il proprio identity provider. Il terzo è GHEC con data residency, che aggiunge a EMU un vincolo geografico sui dati e un dominio di accesso dedicato. Il quarto è GitHub Enterprise Server (GHES), l’appliance che si installa e si gestisce in proprio.
Da amministratore la domanda operativa da cui discende tutto il resto è sempre la stessa: chi crea gli account, e dove vive il dato.
Identità: chi crea gli account e chi li autentica
Con gli account personali l’identità resta dell’utente. L’azienda può imporre SAML single sign-on configurandolo a livello di organization oppure a livello di enterprise account, ma l’account continua a esistere su github.com anche dopo l’offboarding: si revoca l’accesso alle risorse, non si cancella la persona. In compenso quello stesso account può contribuire all’open source, aprire issue ovunque e collaborare fuori dal perimetro aziendale.
Con EMU il modello si ribalta. Gli account vengono creati dall’identity provider tramite SCIM, l’autenticazione avviene esclusivamente sull’IdP con SAML oppure OIDC, e lo username viene generato da GitHub normalizzando un identificatore fornito dall’IdP; nome visualizzato ed email sono governati dall’IdP, non dall’utente. Le restrizioni sono la parte che l’esame ama: un managed user non può creare repository pubblici né gist, non può fare star, watch o fork di repository esterni all’enterprise, non può seguire utenti esterni né essere invitato in organizzazioni fuori dall’enterprise. Può invece forkare repository private e internal dell’enterprise e collaborare all’interno del perimetro. Esiste poi il setup user, un account amministrativo con suffisso _admin usato per configurare autenticazione e provisioning e per rientrare quando l’IdP è irraggiungibile: non accede via SSO, ed è l’unico appiglio in caso di blocco totale del single sign-on.
Dominio di accesso e funzionalità disponibili
Qui sta il vincolo documentato da memorizzare: GitHub Enterprise Cloud with data residency richiede Enterprise Managed Users e vive su un sottodominio dedicato di GHE.com. L’enterprise non si raggiunge più su github.com ma su un indirizzo del tipo octocorp.ghe.com, con le API su api.octocorp.ghe.com. Il sottodominio si sceglie in fase di attivazione insieme alla regione e non è modificabile in seguito: è una decisione di architettura, non un’etichetta.
Cambiare dominio cambia anche il catalogo funzionale. Su GHE.com repository pubblici e gist non esistono per costruzione, conseguenza diretta di EMU, e alcune capability sono assenti o si comportano diversamente: GitHub Marketplace non è disponibile come vetrina (app e action restano installabili dalla sorgente), le dependency insights a livello di organization ed enterprise non mostrano dati, mancano i runner macOS e i registry Maven e Gradle di GitHub Packages, e le migrazioni passano da GitHub Enterprise Importer invece che da GitHub Importer. Attenzione ai workflow copiati da fuori: quelli che chiamano in modo cablato api.github.com falliscono, perché il token di workflow non dà accesso a GitHub.com.
Anche la sicurezza va nominata con i termini attuali. Nella documentazione odierna non c’è più un unico bundle: ci sono GitHub Secret Protection (secret scanning, push protection, custom patterns, delegated bypass) e GitHub Code Security (code scanning con CodeQL, Copilot Autofix, dependency review, auto-triage delle Dependabot alerts) come prodotti distinti da acquistare, mentre dependency graph e Dependabot alerts restano inclusi nei piani. Verifica sempre la disponibilità nello scenario specifico prima di promettere una funzionalità a un team.
GHES e come riconoscere lo scenario dentro la domanda
GHES è un’appliance Linux self-contained che gira su hypervisor (Hyper-V, OpenStack KVM, VMware ESXi) oppure su AWS, Google Cloud e Azure. Il salto rispetto ai tre scenari cloud non è funzionale ma di responsabilità: aggiornamenti, backup con le Backup Utilities, monitoraggio, capacity planning e finestre di downtime pianificate sono a carico tuo, e l’amministrazione passa anche da SSH e dalle command line utilities oltre che dal browser e dalle API. GitHub Connect è l’opzione che collega l’istanza a GitHub.com per riusarne dati e funzionalità. Poiché il comportamento può cambiare da release a release, quando descrivi una procedura GHES dichiara sempre la versione a cui ti riferisci.
La confusione tipica da evitare è rispondere prima di aver identificato lo scenario. “Un utente non riesce a creare un repository pubblico” è un incidente su GHEC con account personali, ma è il comportamento atteso con EMU e su GHE.com. “Come applico una patch di sicurezza all’istanza” ha senso solo su GHES. Nell’esame GH-100 molte alternative sono corrette in un deployment e sbagliate in un altro: leggi prima lo scenario, poi la domanda, e quando lo scenario non è dichiarato cerca gli indizi (un sottodominio GHE.com, la presenza di SCIM, un riferimento al Management Console o a un upgrade pianificato) che lo rivelano.