Le due leve di Actions permissions
Governare Actions significa decidere due cose distinte: dove i workflow possono girare e quali action e reusable workflow possono essere richiamati. Le due leve stanno vicine nella stessa schermata, ma rispondono a domande diverse e nell’esame vengono spesso mescolate.
La prima leva è l’interruttore di perimetro. A livello di enterprise, in Policies › Actions, si sceglie fra Enable GitHub Actions for all organizations, Enable GitHub Actions for specific organizations e Disable GitHub Actions for all organizations. Lo stesso schema si ripete un piano più sotto: l’organizzazione decide se abilitare Actions per tutti i repository, per un elenco selezionato o per nessuno, e il singolo repository può arrivare fino a Disable all. Sull’API REST questi tre stati corrispondono ai valori all, selected e none dei campi enabled_organizations ed enabled_repositories, il che rende la logica evidente: è una lista di inclusione, non un semplice on/off.
La seconda leva riguarda la provenienza del codice eseguito. Le opzioni sono Allow all actions and reusable workflows, Allow enterprise actions and reusable workflows (nella versione di organizzazione o repository il testo nomina il proprietario corrispondente) e Allow enterprise, and select non-enterprise, actions and reusable workflows. Sull’API sono i valori all, local_only e selected del campo allowed_actions. Scegliendo la terza opzione si apre la allow list vera e propria, con tre caselle indipendenti: Allow actions created by GitHub, Allow Marketplace actions by verified creators e l’elenco di pattern espliciti. Accanto vive un’impostazione a sé, Require actions to be pinned to a full-length commit SHA, che è una regola sulla forma della reference, non sull’identità dell’autore.
I pattern seguono una sintassi documentata: OWNER/REPOSITORY@TAG-OR-SHA per le action e OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA per i reusable workflow. Si possono usare caratteri jolly (per esempio octo-org*/*), separare più voci con la virgola ed escludere una reference facendola precedere da !. Attenzione a un punto che l’esame può sfruttare: la documentazione descrive quali reference l’elenco considera permesse, ma non dichiara in quale momento del ciclo di vita di un run il controllo venga applicato. Non affermare quindi che una action fuori elenco faccia fallire lo step o annulli l’intero run: la risposta difendibile è che quella reference non è consentita dalla policy, senza inventare il momento dell’enforcement.
Come si compongono enterprise, organizzazione e repository
La regola di composizione è direzionale e va imparata alla lettera: se una policy è abilitata a livello di enterprise, può essere disabilitata selettivamente nelle singole organizzazioni o nei singoli repository; se invece è disabilitata a livello di enterprise, organizzazioni e repository non possono riabilitarla. Tradotto in pratica: scendendo di livello si può solo stringere, mai allargare. Un enterprise che concede Allow all actions and reusable workflows non sta imponendo nulla, sta solo alzando il tetto; una organizzazione può ancora scegliere l’allow list e un repository può ancora spegnere tutto.
Questo spiega anche i messaggi che si incontrano nelle impostazioni: quando un livello superiore ha già deciso, la pagina avverte che potresti non riuscire a gestire quelle impostazioni perché l’organizzazione è governata da un enterprise con una policy prevalente. Se un amministratore di organizzazione ti segnala controlli in sola lettura, la diagnosi corretta è quasi sempre una policy ereditata, non un problema di ruolo.
Sullo stesso piano vivono le altre policy di Actions: le approvazioni per i workflow che arrivano da fork (Require approval for first-time contributors, Require approval for all outside collaborators e le varianti per i repository privati), le restrizioni sui self-hosted runner — inclusa l’opzione di disabilitarli in tutti i repository di un enterprise con Enterprise Managed Users — e il più recente framework delle workflow execution protections, costruito sui rulesets, che introduce actor rules (chi può innescare un workflow) ed event rules (quali eventi sono ammessi) con la possibilità di provarle in modalità di valutazione prima di applicarle. Su GitHub Enterprise Server l’insieme di opzioni effettivamente presente dipende dalla release dell’istanza: prima di rispondere “esiste” o “non esiste”, verifica nella documentazione della versione installata.
Che cosa la policy non tocca mai
C’è un’eccezione che ricorre in modo insistente nelle domande d’esame. Anche con l’opzione più restrittiva attiva, restano consentiti le local action e i reusable workflow: la documentazione di organizzazione e repository parla di local action referenziate con ./ e $/, e la pagina delle policy di enterprise chiarisce che le policy non limitano mai l’accesso alle action locali sul filesystem del runner, quando il percorso in uses: inizia con ./.
La conseguenza operativa è importante per chi progetta la governance: una allow list non impedisce a un team di eseguire codice proprio, impedisce di attingere a codice altrui. Se l’obiettivo è centralizzare, il pattern è pubblicare action e reusable workflow in repository interni all’organizzazione e impostare l’Access del repository su Accessible from repositories in the organization, così i team consumano una libreria approvata invece di andare sul Marketplace.
I permessi predefiniti del GITHUB_TOKEN
Il GITHUB_TOKEN è un installation access token di una GitHub App che viene creato automaticamente all’avvio di ogni job. Il suo livello di partenza non lo decide lo sviluppatore: lo decide l’amministratore, in Workflow permissions, scegliendo fra Read and write permissions (impostazione permissiva) e l’accesso in sola lettura limitato ai permessi contents e packages (impostazione restrittiva). Sull’API il campo è default_workflow_permissions, con valori read e write. Accanto c’è la casella Allow GitHub Actions to create and approve pull requests, esposta come can_approve_pull_request_reviews: è la leva che impedisce a un workflow di approvare da solo il proprio cambiamento, ed è una domanda classica sui controlli di separazione dei compiti.
Anche qui vale la gerarchia: il default si imposta a livello di enterprise, organizzazione o repository, e i workflow possono poi intervenire con la chiave permissions sull’intero file o sul singolo job, seguendo il principio del privilegio minimo. Il punto da fissare per l’esame è che disciplinare il token è una scelta di governo, non una convenzione di scrittura dei workflow: se la domanda chiede come impedire che ogni job parta con accesso in scrittura sull’intero repository, la risposta sta nelle impostazioni di enterprise od organizzazione, non in una riga di YAML che i team possono dimenticare.