Il mio Vault locale: segreti, certificati e policy su un Mac

Sul mio Mac gira un'istanza locale di HashiCorp Vault che sto adottando come cassaforte per i segreti dei progetti di sviluppo, al posto di file .env sparsi. In questo articolo descrivo come è fatta, perché ho fatto certe scelte e quali punti devo ancora sistemare.

Panoramica

• Versione: Vault 2.2.1 (edizione open source), installato con Homebrew.
• Avvio: un LaunchAgent di macOS (local.vault) con RunAtLoad e KeepAlive, così il servizio parte al login e viene riavviato se si ferma. I log finiscono in un file dedicato.
• Raggiungibilità: solo 127.0.0.1, API sulla porta 8200 e cluster sulla 8201. Nulla è esposto sulla rete.
• Interfaccia: la UI web è attiva, per l'uso quotidiano.

Configurazione del server

Il file vault.hcl è volutamente corto:

• Storage: backend file su disco, in una cartella leggibile solo dal mio utente (permessi 700). Per una macchina singola è la scelta più semplice, senza Raft né Consul.
• TLS: il listener risponde solo in HTTPS, anche in locale. Un client che prova HTTP in chiaro riceve un errore.
• mTLS: il listener conosce anche una CA per i certificati client, quindi può autenticare le applicazioni con un certificato oltre che con un token.
• mlock disattivato: disable_mlock = true, una concessione comune su macOS per un ambiente di sviluppo.

Certificati: una CA locale

Il certificato del server (CN=localhost, SAN localhost e 127.0.0.1) è emesso da una CA privata con una CA intermedia, non è autofirmato. È a vita molto breve: dura circa 24 ore. È una scelta consapevole, perché un certificato che scade ogni giorno obbliga a rendere automatico il rinnovo, che è la cosa giusta da fare.

Cosa c'è dentro

Motori dei segreti

• kv/: KV versione 2, con versionamento dei segreti. Qui stanno le chiavi API usate dalle applicazioni; per esempio la chiave dell'agente AI di un mio strumento di pubblicazione è in un percorso dedicato.
• agent-registry/: un motore per registrare gli agenti (le identità di software autonomi), pensato per collegare ogni agente a un'entità di Vault.
• identity/, cubbyhole/ e sys/: i motori di sistema standard.

Metodi di autenticazione

• token/: i token, sempre presenti.
• userpass/: attivato di recente con un utente personale, per entrare dalla UI senza usare il token amministrativo. Il TTL dei token è di 32 giorni (768 ore).

Policy

• ui-user: per l'uso quotidiano. Dà CRUD sui segreti e poche letture di servizio (stato di salute, mount, rinnovo del proprio token), senza accesso alla gestione di auth, policy e sys/ in scrittura. È il principio del minimo privilegio applicato a me stesso.
• default-ceiling: permette a un'entità di leggere la propria registrazione nell'agent-registry e le policy di default, e nient'altro. Fa da «soffitto» per gli agenti.
• default e root: quelle integrate.

Come lo uso

Per le operazioni quotidiane entro dalla UI con userpass e la policy ui-user, invece che con il token amministrativo. Nel KV tengo le chiavi API dei progetti; l'obiettivo è che le applicazioni le leggano da Vault invece che da file .env, ma la migrazione non è completa: alcuni strumenti usano ancora un .env locale.

Perché non un semplice file .env

Un file .env è comodo ma resta in chiaro sul disco, finisce nei backup e basta un git add distratto per pubblicarlo. Con Vault si ottengono cifratura a riposo, versionamento, policy per ogni persona o agente, e un punto unico in cui ruotare le chiavi. Per un singolo sviluppatore c'è un costo di gestione, ma impone abitudini utili quando i progetti crescono.