Nell'eseguire dei workflow automatizzati ci può capitare di dover eseguire delle operazioni al posto di utenti "normali". Per esempio, quando si crea una pull-request, è un utente che deve creare il branch, fare le modifiche, eseguire il commit e, infine, aprire la pull-request. Quando invece le operazioni sono automatizzate tramite i workflow di GitHub, per esempio, dobbiamo sempre effettuare le operazioni passando un token che identifica chi è l'autore dell'action corrispondente. Questo token potrebbe essere un "Personal Access Token (PAT)", ovvero un token generato a partire da un account "utente", che ha tutte le proprietà e permessi che identificano l'utente. Le operazioni verranno quindi eseguite da una macchina in modo automatizzato, come se fosse però l'utente ad eseguirle.

Sebbene questo approccio sia abbastanza facile da implementare perché basta staccare un token e passarlo alla CLI di GitHub o ad un workflow, non è un approccio molto sicuro e durevole nel tempo. Supponendo infatti che l'account venga disabilitato, anche il token di conseguenza non sarà più valido. Inoltre il token non deve avere una durata infinita, pertanto bisognerà pensare di ruotarlo spesso, ma è una operazione "costosa" da implementare.

A questo scopo entrano in gioco i service account, chiamati anche "GitHub App", che sono proprio degli account di servizio che vengono utilizzati per automatizzare i processi unattended, non eseguiti direttamente da un utente "vero". La GitHub App si può creare altrettanto facilmente su GitHub ed è sufficiente impostare lo scope (es. tutta l'organizzazione o solo alcuni repository) e grantare i permessi del caso, come faremo su un account utente "normale". Per staccare un token abbiamo necessità di sfruttare una estensione della CLI di GitHub:

- name: Install token extension
  shell: bash
  env:
    GH_TOKEN: ${{ github.token }}
  run: gh extension install Link-/gh-token

Supponendo di aver messo nelle secret del repo (o dell'organizzazione) di GitHub il certificato (.pem) rilasciato a valle della creazione della GitHub App, possiamo quindi generare un token semplicemente invocando l'estensione appena installata:

- name: Generate GitHub Token
  shell: bash
  id: gh-token
  env:
    GH_APP_CERTIFICATE: ${{ secrets.GH_APP_CERTIFICATE }}
  run: |
    base_key=$(echo "$GH_APP_CERTIFICATE" | base64 -w 0)
    token=$(gh token generate --app-id 123456 --token-only --base64-key "$base_key")
    echo "token=$token" >> $GITHUB_OUTPUT

Nel primo step andiamo semplicemente a recuperare il certificato e a farne un encoding base64 (rispettando i caratteri di new line), mentre nel secondo generiamo proprio il token e, infine, lo esponiamo in modo che sia utilizzabile negli step successivi del workflow (che varieranno in base al contesto).

- name: Checkout  
  uses: actions/checkout@v4
  with:
    token: ${{ steps.gh-token.outputs.token }}

In questo caso è tutto più sicuro perché il token viene staccato solo nel momento in cui il workflow viene messo in esecuzione, non viene esposto (es. in una secret di GitHub che può essere stampata in chiaro con qualche workaround), e ha una durata tutto sommato breve, relativamente al workflow in esecuzione. Non essendo associato ad un utente, quest'app non avrà mai problema di token scaduti o inutilizzabili.