> ## Content Index
> Fetch the complete content index at: https://reinaldoferro.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Il mio Vault locale: segreti, certificati e policy su un Mac
- URL: https://reinaldoferro.com/il-mio-vault-locale-segreti-certificati-e-policy-su-un-mac/
- Published: 2026-11-07T11:00:00.000Z
- Updated: 2026-11-07T11:00:00.000Z
- Description: Come ho configurato HashiCorp Vault su un Mac: storage su file, TLS con CA locale, KV v2, userpass, policy a privilegio minimo e i limiti ancora da sistemare.
- Author: Reinaldo Ferro
- Tags: Vault, cybersecurity, Open source

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.