Policy di organizzazione e di enterprise

Un solo meccanismo, ripetuto per ogni impostazione

Chi amministra GitHub su scala aziendale lavora su piani sovrapposti: l’enterprise account è il punto centrale di amministrazione e contiene una o più organization, mentre i repository appartengono alle organization e non sono accessibili direttamente sotto l’enterprise. Le policy sono lo strumento con cui l’enterprise decide che cosa le organization possono ancora scegliere da sole.

Il meccanismo è sempre lo stesso e conviene impararlo una volta sola, perché si ripete quasi identico in ogni pagina di Settings. Ogni policy espone alcuni valori concreti più un valore di delega, formulato come “Allow owners to administer the setting on the organization level” oppure, per i token, “Allow organizations to configure access requirements”. Se l’enterprise owner lascia la delega, l’impostazione resta modificabile dagli organization owner e può legittimamente differire fra un’organization e l’altra. Se invece sceglie un valore concreto, quel valore viene imposto ovunque e più in basso il controllo risulta bloccato: la documentazione lato organizzazione lo dice a chiare lettere per i token, “you cannot override the policy in your organization”.

Da amministratore la domanda operativa non è quindi “questa impostazione esiste?” ma “a quale livello è stata fissata?”. Prima di stringere una policy conviene aprire la vista che elenca le configurazioni attuali delle organization, per capire quante ne verranno modificate di colpo.

Repository, fork e collaboratori esterni

Gli esempi più tipici stanno sotto Policies, nella sezione dedicata alla gestione dei repository. Base permissions fissa il livello di accesso implicito dei membri ai repository dell’organizzazione, scegliendo fra None, Read, Write e Admin oppure delegando. Repository creation decide se i membri possono creare repository o se la creazione è riservata agli organization owner, e permette di selezionare quali visibilità sono ammesse fra public, private e internal; nelle organization possedute da un enterprise account la visibilità internal è quella predefinita per i nuovi repository. Nelle configurazioni con Enterprise Managed Users compare in più la possibilità di bloccare la creazione di repository nello spazio personale degli utenti.

Repository forking governa il fork dei repository private e internal, con l’opzione secca “Never allow forking of private or internal repositories” e, quando il fork è consentito, la scelta di dove gli utenti possono forkare. Repository outside collaborators regola l’invito degli outside collaborator e ha tre gradi di severità: consentirlo ai membri, riservarlo agli organization owner oppure riservarlo agli enterprise owner. Ci sono poi Repository visibility change e Repository deletion and transfer, che spostano verso l’alto azioni altrimenti disponibili a chi ha ruolo di admin sul repository.

Due dettagli meritano attenzione perché sono esattamente il genere di cosa su cui si sbaglia. Le policy interagiscono fra loro: se la creazione dei repository è riservata agli organization owner, i membri non possono nemmeno cambiare la visibilità. E disattivare la policy sulle deploy key non si limita a impedire nuove chiavi, disabilita quelle esistenti in tutti i repository dell’enterprise.

Accesso programmatico, Actions e sicurezza

L’accesso via token segue lo stesso schema. La policy Personal access tokens vale separatamente per i token classic e per i fine-grained personal access token, e offre “Allow organizations to configure access requirements”, “Restrict access via personal access tokens” e “Allow access via personal access tokens”; qualunque sia la scelta, i token continuano a raggiungere le risorse pubbliche. Accanto ci sono la durata massima e la richiesta di approvazione, che riguarda solo i token fine-grained e non quelli classic. Il momento in cui la durata viene applicata cambia con il tipo di token: per i fine-grained la verifica avviene alla creazione, perché l’organizzazione di destinazione è già nota, per i classic quando il token viene usato.

Per GitHub Actions l’enterprise sceglie fra abilitarlo per tutte le organization, per organization specifiche o disabilitarlo per tutte; sotto quel livello non si recupera nulla di ciò che è stato spento. La richiesta di autenticazione a due fattori è invece una policy che non ammette deroghe locali.

Sulla sicurezza del codice serve prudenza terminologica: la console e la documentazione attuali parlano di GitHub Secret Protection e GitHub Code Security come prodotti distinti, accanto a GitHub Advanced Security. Qui la regola generale ha un’eccezione documentata: gli organization owner e i security manager possono comunque abilitare le funzionalità di sicurezza, indipendentemente da come è impostata la policy. E vietare un prodotto impedisce di attivarlo su ulteriori repository, ma non lo disattiva dove è già attivo.

Un ultimo caveat architetturale: i ruleset non seguono la logica imponi-o-delega. Ruleset di enterprise, organization e repository che colpiscono lo stesso branch vengono aggregati e, quando la stessa regola è definita in modo diverso, si applica la versione più restrittiva. Su GitHub Enterprise Server il comportamento può dipendere dalla versione dell’istanza, quindi va verificato sulla documentazione della release installata.

Come leggere una domanda su questo argomento

L’esame verifica che sappiate collocare la decisione, non che ricordiate ogni etichetta. Davanti a uno scenario chiedetevi nell’ordine: la policy è stata fissata a livello di enterprise o lasciata in delega? Se è fissata, la risposta corretta è quasi sempre che l’organization non può cambiarla e che l’unica strada è agire sull’enterprise. Se è delegata, la risposta corretta è che l’organization owner interviene da sé.

La confusione tipica da evitare è trattare “impostazione presente nel menu dell’organization” come sinonimo di “impostazione modificabile”. Un’altra è confondere una policy con un ruolo: negare un permesso a livello enterprise non è la stessa cosa che togliere un ruolo a una persona. E ricordate che alcune configurazioni cambiano il quadro a monte, perché la residenza dei dati richiede Enterprise Managed Users, che a sua volta porta con sé restrizioni proprie sui contenuti pubblici.