Condividere segreti in GitHub Actions — nessun Vault necessario

Puoi condividere segreti in GitHub Actions senza HashiCorp Vault usando la GitHub Action di Vaulted, che crea link cifrati e autodistruttivi senza alcuna infrastruttura. Utilizza la cifratura lato client con AES-256-GCM e funziona come un singolo step del workflow — nessun server per la gestione dei segreti, nessuna configurazione cloud richiesta.

Le pipeline CI hanno continuamente bisogno di credenziali temporanee. Una chiave di deploy che dovrebbe esistere solo per una singola esecuzione. Un token passato tra due repository durante una migrazione. Una credenziale ruotata in un workflow e consumata in un altro.

Il consiglio standard è "usa un secrets manager." Ma configurare HashiCorp Vault o AWS Secrets Manager solo per passare una singola credenziale tra workflow è come affittare un magazzino per spedire una lettera.

I repo secret di GitHub gestiscono bene il caso statico — API key longeve, token di deploy, credenziali di account di servizio. Ma non sono sufficienti per tutto ciò che è temporaneo o dinamico.

Il problema: la condivisione temporanea di segreti in CI/CD

I repo secret sono progettati per valori che cambiano raramente e vengono consumati da un singolo repository. Non coprono:

Passaggi una tantum durante la rotazione delle chiavi — Ruoti una credenziale in un workflow e un altro workflow (o team) deve recuperare il nuovo valore esattamente una volta.
Condivisione di credenziali tra repository — Due repo devono scambiarsi un token di breve durata, ma nessuno dei due dovrebbe conservarlo in modo permanente.
Accesso temporaneo per collaboratori esterni — Un token CI che dovrebbe scadere al termine della finestra di deploy di un collaboratore esterno.
Sapere quando un segreto è stato consumato — I repo secret non offrono alcuna visibilità su se o quando un valore è stato letto.

Sono problemi temporanei che richiedono una soluzione temporanea.

Un approccio più leggero: link cifrati autodistruttivi

La Vaulted GitHub Action ti permette di creare e recuperare segreti cifrati e autodistruttivi direttamente dai tuoi workflow — nessuna infrastruttura da gestire.

Creare un segreto:

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

Lo step produce un URL contenente il segreto cifrato. La chiave di cifratura risiede nel frammento dell'URL, quindi non raggiunge mai i server di Vaulted.

Recuperare un segreto:

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Dopo il recupero, il link viene consumato e il ciphertext lato server viene eliminato. Il segreto esiste solo nella memoria del runner per la durata di quel job.

Modello di sicurezza

Tre caratteristiche rendono questo approccio sicuro per l'uso in CI/CD:

Cifratura zero-knowledge. Il segreto viene cifrato con AES-256-GCM all'interno del runner GitHub prima di lasciare il processo. La chiave di cifratura è incorporata nel frammento dell'URL, che non viene mai inviato al server. Vaulted conserva solo il ciphertext che non è in grado di decifrare. Questa è la cifratura lato client applicata al CI/CD.
Mascheramento automatico dei log. L'action chiama core.setSecret prima di core.setOutput, registrando ogni riga del valore segreto nel mascheratore di log di GitHub. I segreti su più righe vengono mascherati riga per riga, in modo che anche le corrispondenze parziali vengano oscurate dai log del workflow.
Link autodistruttivi. I limiti di visualizzazione e la scadenza temporale vengono applicati lato server. Un segreto creato con views: 1 e expires: 1h viene eliminato definitivamente dopo il primo recupero o dopo un'ora — a seconda di quale evento si verifica prima.

Quando usare questo approccio invece di un secrets manager

Scenario	Secrets manager	Vaulted Action
Credenziali di produzione longeve	Sì	No
Configurazione runtime dell'app (DB URL, API key)	Sì	No
Passaggio una tantum di credenziali tra workflow	Eccessivo	Sì
Condivisione temporanea di token tra repository	Eccessivo	Sì
Accesso CI temporaneo per collaboratori esterni	Eccessivo	Sì
Distribuzione delle credenziali dopo una rotazione	Eccessivo	Sì

I secrets manager sono lo strumento giusto per i segreti che le applicazioni consumano a runtime. Vaulted è per il passaggio — il momento in cui una credenziale si sposta da un posto all'altro e non dovrebbe persistere.

Per iniziare

Aggiungi l'action a qualsiasi workflow:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Trovala nel GitHub Marketplace. I segreti creati dall'action sono compatibili con la web app e la CLI — tutto ciò che viene creato in uno può essere recuperato dall'altro.

Nessun server Vault. Nessuna policy IAM. Nessuna infrastruttura. Solo link cifrati che si autodistruggono.

Il problema: la condivisione temporanea di segreti in CI/CD

Un approccio più leggero: link cifrati autodistruttivi

Modello di sicurezza

Quando usare questo approccio invece di un secrets manager

Per iniziare

Articoli correlati