Le pipeline ricevono solo i segreti che concedi
Un token di servizio viene creato nel tuo browser e mostrato una sola volta; il server conserva solo le sue chiavi pubbliche. Concedigli gli ambienti di cui una pipeline ha bisogno e aggiungi un vincolo OIDC, così funziona solo all’interno del repository e del branch giusti.
- I token leggono solo ciò che concedi
- Vincolo OIDC per GitHub, GitLab e Bitbucket
- Production può restare del tutto fuori dalla CI
Un token che non può aprire più di quanto gli hai dato
Un token crunu_svc_ viene generato interamente nel browser dell’amministratore e mostrato una sola volta. Legge solo gli ambienti che concedi: un token per development non riceve mai la chiave di production.
- Lease, utilizzi e retiAssegna a un token un lease, un limite di utilizzi da 1 a 1.000.000 e le reti da cui può arrivare.
- Legato al tuo repositoryCon un vincolo OIDC, il token funziona solo insieme al token del tuo provider CI per il repository, il branch e l’ambiente di deployment che hai scelto. Un token del provider riproposto viene rifiutato.
- Ogni utilizzo viene registratoGli accessi e i rifiuti dei token compaiono nel registro di audit, e un token CI riproposto genera un avviso.
Tre righe nella pipeline
Salva il token tra le variabili segrete della tua CI come CRUNU_TOKEN, installa una versione fissata di crunu ed esegui il passaggio tramite crunu run. Le variabili vengono decifrate in memoria e niente viene scritto su disco.
- Un’installazione fissata e verificataL’app mostra il comando di installazione con i checksum esatti del manifest di rilascio firmato.
- Wrapper pronti all’usoUna GitHub Action, un template GitLab e una pipe Bitbucket installano una versione fissata e ne verificano lo SHA-256.
- I codici di uscita passano
crunu runrestituisce il codice di uscita del programma eseguito, quindi un test fallito fa comunque fallire il passaggio.
Cosa può verificare ogni sistema CI
L’agente trova da solo il token del provider CI in GitHub Actions, GitLab CI e Bitbucket Pipelines. Qualsiasi altra CI funziona con un token salvato tra i suoi segreti.
| Sistema CI | Cosa verifica il vincolo OIDC | Wrapper |
|---|---|---|
| GitHub Actions | Repository, ref, ambiente di deployment | Action setup-crunu, copiata nel tuo repository |
| GitLab CI | Percorso del progetto, ref, tipo di ref, ambiente di deployment | Template .crunu e .crunu-oidc |
| Bitbucket Pipelines | Repository, branch, ambiente di deployment | Una pipe crunu run, con un’immagine costruita da te |
| Qualsiasi provider OIDC | Qualsiasi emittente, chiavi tramite OIDC Discovery | Token e crunu run |
| Qualsiasi CI senza OIDC | Solo il token | Token e crunu run |
Tieni production fuori dalla pipeline
La configurazione consigliata non fa mai passare i segreti di produzione attraverso la CI. L’agente gira sulla macchina di produzione, e la pipeline si limita a riavviare il servizio.
- La macchina si procura i suoiIl server di produzione è registrato come macchina e riceve direttamente il suo ambiente.
- La CI si limita a riavviareIl passaggio di deploy riavvia il servizio;
crunu run --restart on-changelo riavvia anche quando i valori cambiano. - Quando la CI deve toccare productionUsa un token di produzione separato con un vincolo OIDC, approvato da un Owner, con ogni consegna nel registro di audit.
Cosa sapere prima di collegarlo
I token tengono production fuori portata. Alcune parti dell’uso con la CI sono ancora ricette, non pulsanti.
- I wrapper non sono nei marketplaceCopia la GitHub Action nel tuo repository, e costruisci e pubblica tu stesso l’immagine della pipe Bitbucket.
- Nessuna sincronizzazione integrata con le piattaformeNessuna integrazione invia i valori a Vercel, Cloudflare, AWS Secrets Manager o GitHub Secrets. La via documentata è una ricetta con crunu run.
- Il passaggio legge ciò che riceveQualsiasi cosa giri all’interno del job vede le variabili che riceve. Concedi l’insieme di ambienti più piccolo possibile.
- Lega i token di produzioneUn token senza vincolo OIDC funziona da qualsiasi indirizzo consentito finché non viene revocato o non raggiunge la scadenza del lease o il limite di utilizzi.
Risposte alle domande più comuni
Altre domande? Scrivi a support@crunu.com
Se un token trapela, può leggere production?
No, a meno che tu non gli abbia concesso production. Un token di development non riceve mai la chiave di production. Con un vincolo OIDC, un token trapelato non funziona affatto senza il token del tuo provider CI per il repository e il branch giusti.
Mi serve OIDC?
No. Qualsiasi CI può usare un token di servizio salvato tra i suoi segreti. OIDC aggiunge un secondo controllo che lega il token al tuo repository e al tuo branch.
Dove viene conservato il token?
Tra le variabili segrete della tua CI. Il server conserva solo le chiavi pubbliche del token, ed è per questo che viene mostrato una sola volta e non può essere recuperato.
Un token può essere usato solo poche volte?
Sì. Imposta un limite di utilizzi da 1 a 1.000.000, più un lease e le reti consentite.
Crunu può inviare variabili a Vercel o Cloudflare?
Non con una sincronizzazione integrata. Puoi farlo da un passaggio della pipeline con crunu run e il comando della piattaforma stessa, usando un token con vincolo OIDC.
Togli i segreti di produzione dalla tua pipeline
Crea un token per un ambiente di staging ed esegui i tuoi test con crunu run.