I segreti arrivano ai server che li usano, non alla pipeline nel mezzo
L’agente crunu gira sui tuoi server Linux, tiene in memoria gli ambienti decifrati e avvia i tuoi programmi con quelle variabili. La CI riceve un token per l’ambiente che compila, legato a un solo repository e a un solo branch. I valori di produzione non devono affatto passare dalla CI.
Le domande che fanno i team come il tuo
Le domande che emergono quando un team come il tuo sposta i propri segreti in un unico posto. La guida qui sotto risponde a ciascuna di esse.
- Come riceve un server il suo ambiente senza un file su disco?
- Come teniamo i valori di produzione fuori dalla CI?
- Come leghiamo un token CI a un solo repository e a un solo branch?
- Cosa succede ai servizi in esecuzione se il vault non è raggiungibile?
- Quanto ci mette la revoca di una macchina a fare effetto?
- Possiamo fornire production solo alle nostre reti?
- Chi può registrare le macchine senza vedere i valori?
- Come fa uno script di deploy a capire perché crunu non è riuscito?
Le parti di Crunu che lo coprono
Ogni parte segue la stessa regola: il server conserva testo cifrato, chiavi pubbliche e documenti firmati, e non possiede mai una chiave che apra i tuoi valori.
Macchine
Registra un server con un codice monouso: l’agente crunu tiene i suoi ambienti in memoria e avvia i tuoi programmi con quelle variabili.
Scopri di più
CI/CD
Dai a ogni pipeline un token di servizio limitato ai suoi ambienti e legalo al tuo provider CI con OIDC, così un token trapelato non può accedere da solo.
Scopri di più
Regole di rete
Fornisci il contenuto di un ambiente solo alle reti IPv4 e IPv6 consentite, con regole firmate che non possono essere allentate di nascosto.
Scopri di più
Registro di audit
Accessi, concessioni, versioni, rotazioni e rifiuti finiscono in un registro a catena di hash che puoi verificare con un clic ed esportare.
Scopri di più
Controllo degli accessi
Dai a ogni persona, macchina e pipeline solo gli ambienti che le servono, con ruoli garantiti dalle chiavi di cifratura e non soltanto dai controlli del server.
Scopri di più
Come funziona per team di piattaforma
In questa pagina
Dove i segreti sfuggono lungo la strada verso un processo
Portare un valore dentro un processo in esecuzione è il punto in cui di solito sfugge: un .env incorporato in un’immagine, una chiave di produzione salvata nelle variabili della CI, un utente di deploy che può leggere tutto.
Il lavoro è che ogni macchina e ogni pipeline ricevano esattamente i propri ambienti, che nulla finisca su disco se non lo scegli tu, e che la revoca sia un’unica azione.
Quattro passaggi da un nuovo server a un servizio in esecuzione
- Crea la macchina. Scegli i suoi ambienti e come fornirli: la chiave dell’ambiente (Environment key), che dà sempre l’ultima versione di ogni file, oppure i file selezionati (Selected files), una copia sigillata dei soli file di cui la macchina ha bisogno. I file selezionati si possono revocare senza cambiare la chiave dell’ambiente.
- Installa e registra. La finestra Enroll machine mostra un unico comando che installa l’agente, ne controlla lo SHA-256 e registra la macchina con un codice monouso. Il codice è valido per 15 minuti per impostazione predefinita e per 24 ore al massimo, e viene letto da stdin o da una variabile, mai da un argomento.
- Approva tramite l’impronta.
crunu enrollstampa l’impronta della macchina. Approva la macchina dopo aver verificato che corrisponda a quella nell’app. - Avvia il servizio tramite l’agente. L’utente del servizio deve far parte del gruppo
crunu. Con--restart on-change, il programma si riavvia con i nuovi valori dopo che sono cambiati.
# /etc/systemd/system/payments-api.service
[Service]
User=payments
ExecStart=/usr/local/bin/crunu run --env payments-api/production --restart on-change -- /opt/payments-api/bin/serverCosa fanno per te l’agente e i token
| Esigenza | Cosa fa Crunu |
|---|---|
| Nessun segreto su disco | Il servizio dell’agente tiene gli ambienti decifrati solo in memoria e li passa a crunu run tramite un socket locale aperto al gruppo crunu. Vedi systemd. |
| File dove uno strumento se li aspetta | crunu pull scrive i file con permessi 0600 in due fasi, conserva la versione precedente come .prev, non segue i link simbolici e rifiuta i file di avvio della shell, .ssh/ e le directory di systemd. --env-out scrive un unico file env per EnvironmentFile=. |
| Un agente che puoi verificare | Un binario Go statico che usa solo la libreria standard. Su Linux è protetto dagli altri processi dello stesso utente, i core dump sono disattivati e il servizio gira in una sandbox di systemd. Gli aggiornamenti controllano una firma Ed25519. |
| Server che superano un’interruzione | L’agente controlla il server ogni minuto e rinnova il suo lease ogni 5 minuti. Se il server non è raggiungibile, fornisce l’ultimo stato verificato fino alla fine del lease, 24 ore per impostazione predefinita. |
| CI senza production | I token di servizio ricevono solo gli ambienti che concedi, con un lease, un limite di utilizzi e delle reti. Un vincolo CI (OIDC) lega un token a un repository, a un branch e a un ambiente di deployment in GitHub Actions, GitLab CI, Bitbucket Pipelines o con qualsiasi emittente OIDC. Un token CI riproposto viene rifiutato. |
| Production solo da reti note | Elenchi di reti firmati e regole di rete dell’ambiente per IPv4 e IPv6. Restringere ha effetto subito; allentare richiede un’attesa di 15 minuti con un avviso e la possibilità di annullare, oppure ha effetto subito con una seconda firma. I pass delle macchine coprono i cambi di indirizzo, 24 ore per impostazione predefinita. |
| Revoca in un’unica azione | Revocare una macchina cancella i suoi ambienti dalla memoria entro pochi minuti, mentre la macchina è online, e ruota le chiavi degli ambienti che aveva. Un codice di registrazione riutilizzato segnala una possibile intercettazione. |
| Segnali | Avvisi per accessi da nuovi dispositivi, codici di registrazione riutilizzati, macchine su nuovi indirizzi, token CI riproposti, lease scaduti ed eventi di rete, inviati a un webhook firmato con HMAC o per email. Slack, Microsoft Teams e PagerDuty si collegano tramite i loro webhook in entrata. |
Errori che puoi distinguere
Quando crunu non riesce a consegnare le variabili, il suo codice di uscita dice perché, così uno script di deploy può reagire. Altrimenti crunu run restituisce il codice di uscita del tuo programma.
| Codice | Significato |
|---|---|
3 | La macchina non è registrata, oppure nessuno ha effettuato l’accesso |
4 | L’accesso è stato revocato o il lease è scaduto |
5 | Nessuna connessione e nessuno stato verificato valido |
6 | Il controllo di una firma o di un certificato non è riuscito |
7 | Questo indirizzo non è consentito dalla regola di rete dell’ambiente |
Dove si ferma l’agente
- Il servizio gira su Linux con systemd. Su macOS
crunufunziona come strumento da riga di comando, senza servizio in background. Non esiste una build per Windows. - Nessun operatore Kubernetes, chart Helm o driver CSI, nessun provider Terraform e nessun SDK. I programmi ricevono i valori tramite
crunu run. - Nessuna sincronizzazione integrata verso Vercel, Cloudflare, AWS Secrets Manager o GitHub Secrets. Puoi inviare i valori dalla CI con
crunu rune la CLI della piattaforma stessa. - Nessun segreto dinamico. Crunu non genera password di database a breve durata; servirebbe una chiave sul server.
- Una macchina è un destinatario legittimo. Root su quella macchina può leggere ciò che le è stato dato, e un processo in esecuzione conserva le sue variabili finché non si riavvia.
- Le restrizioni di rete le applica il server, non la cifratura. Un server compromesso non le rispetterebbe, e tutte le macchine dietro uno stesso NAT hanno lo stesso indirizzo.
Ogni limite, con cosa fare al riguardo, è nella pagina delle limitazioni.
Se gestisci anche il server
I team che vogliono il server in casa possono eseguirlo su Docker, Cloudflare Workers, Vercel o Google Cloud Run, e spostarsi dall’uno all’altro con un unico archivio che non contiene valori in chiaro. Un comando doctor controlla un deployment, e un endpoint di stato espone le metriche in formato Prometheus. Il server non è pubblicato come download pubblico. Scrivi a support@crunu.com. La pagina sul self-hosting confronta le piattaforme.
Documentazione e integrazioni correlate
- Installare l’agente su un server
- Macchine e lease
- crunu run
- crunu pull
- Registrare una macchina ed eseguire il servizio
- Variabili d’ambiente e codici di uscita
- Legare un token di servizio alla CI con OIDC
- Limitare production alla rete dell’ufficio
- Self-hosting: panoramica e piattaforme
- systemd
- Docker
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
Dubbi frequenti
Non trovi la risposta? Scrivi a support@crunu.com e ti risponderà una persona.
Cosa succede ai servizi in esecuzione se Crunu non è raggiungibile?
Continuano a funzionare. L’agente fornisce l’ultimo stato verificato fino alla fine del lease, 24 ore per impostazione predefinita. Se non c’è uno stato valido, crunu run termina con il codice 5.
Quanto ci mette la revoca di una macchina a fare effetto?
Pochi minuti, mentre la macchina è online: l’agente controlla il server ogni minuto e cancella i suoi ambienti appena viene revocato. Una macchina che resta offline perde l’accesso alla fine del suo lease.
La CI può fare il deploy in production senza vedere i segreti di produzione?
Sì, ed è la configurazione che Crunu consiglia. Il server di produzione esegue l’agente e scarica da solo il proprio ambiente; la pipeline consegna il codice e riavvia il servizio.
crunu funziona nei container?
Lo script di installazione ha una modalità senza root pensata per CI e container, testata nelle immagini node:24, Ubuntu 24.04 e Alpine 3.22. Con un token di servizio, crunu accede e decifra all’interno del proprio processo, senza file di stato.
Qualcuno può registrare macchine senza vedere alcun valore?
Sì. Il ruolo Operator su un ambiente non ha chiave: aggiunge le macchine e chiede l’accesso per loro, e un proprietario o un amministratore approva.
Supportate Kubernetes?
No. Non esiste un operatore, un chart Helm o un driver CSI.