Gestione dei segreti con GitHub

In qualsiasi progetto software è spesso necessario utilizzare informazioni sensibili, come chiavi API, credenziali del database o token di accesso. Memorizzarle direttamente nel codice o nel repository rappresenta un grave rischio per la sicurezza.

La gestione dei segreti consiste nell'archiviare e amministrare in modo sicuro questi dati sensibili. Garantisce che solo i sistemi e gli utenti autorizzati possano accedervi, impedendone l'esposizione non autorizzata.

GitHub offre un modo sicuro per archiviare le informazioni sensibili, denominato GitHub Secrets. Si tratta di variabili d'ambiente crittografate che è possibile utilizzare nei workflow GitHub Actions.

• Per impostazione predefinita, non vengono scritte nei log.
• Dopo la creazione, non sono visibili nell'interfaccia.
• Sono accessibili solo dai workflow selezionati.

In questo modo le credenziali sono protette dall'esposizione accidentale.

È possibile definire i segreti a diversi livelli: repository, ambiente o organizzazione. Nella maggior parte dei casi si inizia dai segreti del repository.

Per crearne uno:

1. Acceda alla scheda Impostazioni del repository.
2. Vada a Segreti e variabili > Actions.
3. Faccia clic su Nuovo segreto del repository.

Assegni un nome univoco, ad esempio API_KEY, e incolli il valore del segreto.

Una volta definito un segreto, è possibile utilizzarlo nei file YAML del workflow. GitHub Actions inserisce automaticamente i segreti come variabili d'ambiente nei job.

È possibile accedervi usando il contesto ${{ secrets.SECRET_NAME }}. Questo script simula un passaggio che userebbe un segreto di questo tipo. Per eseguirlo, supponga che MY_API_KEY sia impostata come variabile d'ambiente da GitHub Actions.

Oltre ai segreti del repository, GitHub offre altri due ambiti più potenti:

• Segreti dell'organizzazione: disponibili in più repository all'interno di un'organizzazione. Sono utili per i segreti condivisi tra molti progetti, come un token di deploy aziendale.
• Segreti dell'ambiente: associati ad ambienti di deploy specifici, come staging e production. Possono avere regole di protezione, ad esempio la richiesta di un'approvazione manuale prima del deploy.

Per la massima sicurezza, utilizzi sempre l'ambito più ristretto necessario.

OpenID Connect (OIDC) è un livello di autenticazione basato su OAuth 2.0. È uno standard che consente ai client di verificare l'identità di un utente finale sulla base dell'autenticazione eseguita da un server di autorizzazione.

Nel CI/CD, OIDC consente ai workflow di autenticarsi in modo sicuro presso i provider cloud, come AWS, Azure e GCP, senza dover archiviare credenziali a lunga durata, come le chiavi API, nei GitHub Secrets.

GitHub Actions può agire come provider OIDC. Quando viene eseguito un workflow, GitHub genera un token OIDC univoco e a breve durata per quel job specifico.

Questo token contiene claim verificabili sul workflow, come il repository, il branch e l'ID del job. I provider cloud possono quindi essere configurati per considerare attendibili i token emessi da GitHub e concedere un accesso temporaneo sulla base di questi claim.

L'uso di OIDC con GitHub Actions offre vantaggi significativi per la sicurezza:

• Nessuna credenziale a lunga durata: non è necessario archiviare chiavi API cloud statiche nei GitHub Secrets.
• Rischio ridotto: i token a breve durata limitano l'impatto di un'eventuale compromissione.
• Accesso granulare: i ruoli cloud possono essere associati a condizioni specifiche del workflow, ad esempio consentendo il deploy solo dal branch main.
• Audit: è più facile tenere traccia di chi ha fatto cosa, poiché le identità sono associate all'esecuzione del workflow.

Per utilizzare OIDC, è necessario configurare il provider cloud, ad esempio AWS IAM, Azure AD o GCP IAM, affinché consideri attendibile l'emittente OIDC di GitHub.

In genere, ciò comporta:

1. Configurare un Identity Provider (IdP) nell'account cloud.
2. Definire un ruolo o una policy che conceda autorizzazioni specifiche.
3. Aggiungere una "Trust Policy" al ruolo, consentendo ai token OIDC di GitHub di assumerlo, spesso con condizioni basate sui claim del token, ad esempio consentendo l'accesso solo da un repository specifico.

Il workflow richiede quindi un token e lo utilizza per autenticarsi.

Ha appreso come utilizzare GitHub Secrets per archiviare dati sensibili e OpenID Connect per l'autenticazione al cloud senza credenziali.

Quali delle seguenti affermazioni sulla gestione dei segreti in GitHub Actions sono VERE?

Ottimo lavoro! Ha imparato a gestire in modo sicuro i dati sensibili nelle pipeline CI/CD.

• GitHub Secrets fornisce un'archiviazione crittografata per chiavi API e token all'interno del repository, dell'organizzazione o di ambienti specifici.
• OpenID Connect (OIDC) offre un modo ancora più sicuro per autenticarsi presso i provider cloud, utilizzando token verificabili e a breve durata invece di credenziali statiche.

Queste pratiche sono fondamentali per creare pipeline DevOps solide e sicure.