Le Secrets Engines sono il cuore di Vault - permettono di concepire la sicurezza non solo come questione di archiviazione, ma come un processo. Che si tratti di password di database, accesso SSH o firma JWT: tutto può essere gestito in modo dinamico, sicuro e tracciabile - a patto di conoscere le giuste Engines e di utilizzarle correttamente. La chiave non sta tanto nella varietà, quanto nella comprensione e nel design. Chi desidera utilizzare Vault in modo produttivo non può prescindere da una profonda comprensione delle Secrets Engines.
Questo articolo offre una panoramica approfondita su funzione, possibilità d’impiego e ciclo di vita delle Secrets Engines - dai moduli generici come KV, Transit o PKI fino ai moduli specializzati per Cloud e piattaforme database.
Cosa sono le Secrets Engines?
Le Secrets Engines sono componenti specializzate all'interno di Vault, che memorizzano, generano, cifrano dati riservati o eseguono azioni per conto dell’utente. Si può immaginare una Secrets Engine come una sorta di "Pluggable Service", attivato in Vault tramite un percorso dedicato e che, a seconda del tipo, svolge compiti differenti.
Alcune Secrets Engines servono principalmente come archivio sicuro - paragonabile a un Redis o Memcached cifrato. Altre invece interagiscono con sistemi esterni e generano in modo dinamico credenziali di accesso, ad esempio per AWS IAM, database Oracle o accessi SSH. Altre ancora offrono servizi crittografici come Encryption as a Service, generazione di TOTP e QR-Code o rilascio di certificati.
Dal punto di vista tecnico, ogni Secrets Engine funziona come un file system virtuale con cui l’utente interagisce tramite operazioni come read, write o delete. Una richiesta a Vault viene automaticamente indirizzata al percorso corrispondente in cui l’Engine è stata “montata”. Ogni Engine definisce il proprio insieme di percorsi e funzioni.
Tipi di Secrets Engines: panoramica sull’ecosistema Vault
Vault offre un’ampia gamma di Secrets Engines, che possono essere suddivise grossolanamente in due categorie:
Secrets Engines specializzate
Queste Engines sono orientate a piattaforme e servizi specifici e richiedono in genere una profonda conoscenza tecnica della piattaforma di destinazione:
- Cloud: AWS, Azure, Google Cloud, AliCloud
- Database: Cassandra, Couchbase, ElasticSearch, HANA, IBM DB2, Influx DB, MongoDB, MongoDB Atlas, MSSQL, MariaDB, MySQL, Oracle Database, PostgreSQL, Redis, Redis Elasticache, Redshift, Snowflake
- Servizi di identità: Kerberos, LDAP, vari servizi cloud incl. OCI, RADIUS, SAML, JWT/OIDC, Okta, Github, CloudFoundry, ecc.
- Strumenti infrastrutturali: Consul, Nomad, Terraform Cloud
- Messaging: RabbitMQ
- Altro: Venafi, SSH, TOTP, Transform, vari KMS esterni, ecc.
Importante: un Vault Engineer non può essere esperto di ogni piattaforma. La corretta configurazione di queste Engines richiede spesso una stretta collaborazione con esperti di dominio della rispettiva piattaforma.
Secrets Engines generiche
Queste Engines fanno parte del repertorio standard e dovrebbero essere familiari a ogni utente Vault:
- Cubbyhole: Archiviazione temporanea legata al token. Ideale per Secrets privati e volatili che devono essere mantenuti solo in memoria e possono (o devono) andare persi dopo un riavvio del server.
- Key/Value (KV): Probabilmente l’Engine più diffusa per la definizione di chiavi e valori associati, ad esempio username e password. KV v2 supporta il versionamento, mentre KV v1 è considerata obsoleta.
- Database: Supporta oltre 13 piattaforme tramite plugin e consente la creazione e la revoca automatica di credenziali database.
- Transit: Fornisce servizi di cifratura senza archiviazione. Ideale per applicazioni che elaborano localmente dati sensibili ma necessitano di una gestione centralizzata delle chiavi.
- PKI: Crea e gestisce certificati X.509 - indispensabile per soluzioni CA interne.
- Identity: Consente l’associazione di identità, la gestione di alias e l’assegnazione di policy.
Secrets Engines rilevanti per l’esame
Per un esame di certificazione come Vault Associate e Vault Operations Professional, è importante conoscere bene queste Secret Engines:
- Cubbyhole
- KV
- Identity
- PKI
- Database
- Transit
Approfondiremo queste Engines in articoli separati dedicati.
Lifecycle delle Secrets Engines
Ogni Secrets Engine attraversa tipicamente un ciclo di vita: viene
- attivata,
- configurata,
- utilizzata,
- regolarmente "ottimizzata", e
- in molti casi d’uso anche disattivata.
Le Secrets Engines che generano dati dinamici (ad es. per database generati automaticamente, account cloud o tenant) non devono solo essere attivate, ma anche modificate regolarmente (ottimizzate) e, al più tardi con la rimozione della relativa componente infrastrutturale, disattivate. Questo non rappresenta solo una pulizia, ma è anche una prova fondamentale per il mantenimento della qualità dei dati e il rispetto delle normative, come i requisiti di protezione dei dati. Per questo motivo, l’auditabilità di ogni azione è una parte centrale dell’architettura di sicurezza di Vault.
Attivazione e isolamento delle Secrets Engines
Per poter utilizzare una Secrets Engine, questa deve prima essere attivata - tramite la CLI, la API o la UI.
Le Secrets Engines devono essere attivate esplicitamente dall’utente (fanno eccezione Cubbyhole e Identity, attive di default). L’attivazione avviene su un percorso univoco e liberamente definibile, che funge da mount point. Vault applica i seguenti principi:
- Percorsi case-sensitive: kv/ e KV/ sono mount distinti
- Nessun conflitto di nomi: Un mount foo/ impedisce foo/bar/
- Ogni Engine è isolata: Accesso solo ai propri dati
Caratteristiche importanti che ogni engineer e utente finale dovrebbe sempre ricordare - e che possono sempre comparire in un esame di certificazione:
- Attive di default: Le Engines Cubbyhole e Identity sono già attivate e non possono essere disattivate.
- Attivazione manuale: Tutte le altre Engines richiedono un’attivazione esplicita.
- Metodi di attivazione: L’attivazione può avvenire tramite la linea di comando (CLI), l’API o l’interfaccia utente (UI).
- Interazione tramite percorsi: Tutte le interazioni con una Secrets Engine avvengono tramite il suo percorso.
- Percorsi isolati: Ogni Engine attivata è completamente isolata dal resto del sistema - sia logicamente che fisicamente. In presenza di multitenancy, anche le Engines con lo stesso mount point (percorso) sono tra loro isolate.
- Nomi di percorso flessibili: I percorsi non devono corrispondere necessariamente al nome o al tipo della Secrets Engine.
- Case-sensitive: Il percorso è sensibile a maiuscole e minuscole. Un’Engine sotto kv/ non è identica a KV/.
In background, ogni Engine attivata riceve un percorso di memorizzazione generato casualmente e basato su UUID nello storage layer di Vault. Questo percorso è paragonabile a un chroot. Questa "Barrier View" garantisce che un’Engine possa accedere solo ai propri dati. Anche in caso di compromissione di una Engine, l’accesso ad altre Secrets Engines è escluso, anche all’interno dello stesso namespace (tenant).
Pro Tip: È consigliabile sviluppare una convenzione di denominazione coerente per le proprie Secrets Engines, adatta all’organizzazione. Se si utilizzano namespaces, convenzioni vincolanti sui nomi possono ridurre significativamente la complessità del sistema complessivo, il rischio e il carico operativo.
Attivazione tramite linea di comando
Il comando vault secrets è il punto di ingresso principale per la gestione delle Secrets Engines tramite la CLI. I sottocomandi principali sono:
- disable: Disattiva una Secrets Engine
- enable: Attiva una nuova Secrets Engine
- list: Elenca tutte le Secrets Engines attivate
- move: Sposta una Secrets Engine da un percorso a un altro
- tune: Configura i parametri di una Secrets Engine
Esempi
1. Attivazione della Secrets Engine KV (Key/Value) sul percorso predefinito
[rramge@ol9 ~]$ vault secrets enable kv Success! Enabled the kv secrets engine at: kv/ [rramge@ol9 ~]$
Verifica:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
Qui si vede, oltre alla Secrets Engine KV, anche le Secrets Engines Cubbyhole e Identity, che come già menzionato sono sempre presenti. La Engine "system" non è destinata alla memorizzazione dei dati, ma alla gestione operativa di Vault stesso - ne parleremo in articoli futuri, se necessario.
2. Attivazione della Secrets Engine KV (Key/Value) su un percorso personalizzato:
In questo caso si aggiunge anche l’argomento --path=<mount-point>:
[rramge@ol9 ~]$ vault secrets enable -path=mykv kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Verifica:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_5fa9f096 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
3. Attivazione della Secrets Engine KV (Key/Value) con descrizione aggiuntiva
È anche possibile aggiungere l’argomento --description:
[rramge@ol9 ~]$ vault secrets enable -path=mykv --description="My K/V Secret Store" kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Il risultato sarà il seguente:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_645ae3a2 My K/V Secret Store sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
4. Disattivare una Secrets Engine
Disattiviamo ora le due Secrets Engines su kv/ e mykv/:
[rramge@ol9 ~]$ vault secrets disable mykv Success! Disabled the secrets engine (if it existed) at: mykv/ [rramge@ol9 ~]$ vault secrets disable kv Success! Disabled the secrets engine (if it existed) at: kv/ [rramge@ol9 ~]$
Attenzione: Se disattivate una Secrets Engine esistente che contiene già dei Secrets, c’è il rischio di perdita dei dati! La disattivazione di una Secrets Engine elimina tutti i dati associati – è fortemente consigliato eseguire un backup preventivo, in particolare per Engines persistenti come KV o PKI.
Attivazione tramite API con Terraform
Oltre alla CLI, è disponibile anche un controllo dichiarativo tramite API usando Terraform. Potete trovare un modulo Terraform per la gestione delle Secret Engines e delle loro proprietà qui: https://github.com/ICT-technology/terraform-vault-mount/
Questo modulo è un modulo dinamico per la creazione e la gestione di più Secret Engines in una singola invocazione del modulo. Intercetta in modo proattivo gli errori API, implementa le best practice nella gestione delle Secret Engines e supporta pipeline di test automatizzate tramite terraform test.
Esempio d’uso
Troverete un esempio funzionante nella sottocartella examples/. Impostate correttamente le variabili d’ambiente $VAULT_ADDR e $VAULT_TOKEN e l’esempio dovrebbe essere eseguibile direttamente da questa sottocartella - assicuratevi tuttavia di eseguirlo in un ambiente di sviluppo privato e non in un ambiente di produzione.
Il modulo crea le seguenti Secrets Engines:
- kv-v2
- pki
- kubernetes
- ldap
- transit
- aws
Dopo un terraform apply eseguito con successo, il modulo restituirà un elenco dei mount-accessors delle Secrets Engines create. Questi mount-accessors possono essere utilizzati come riferimenti nelle configurazioni di altre risorse Terraform, ma anche per argomenti come auditing e assegnazioni dinamiche di policy.
examples/main.tf:
### BEGIN FILE: examples/main.tf ###
module "vault\_mounts" {
source = "git::[https://github.com/ICT-technology/terraform-vault-mount.git?ref=v2025.1.3](https://github.com/ICT-technology/terraform-vault-mount.git?ref=v2025.1.3)"
mounts = {
kvv2 = {
path = "kv-v2"
type = "kv-v2"
description = "Key-Value Version 2 Secrets Engine"
options = { version = "2" }
}
```
pki = {
path = "pki"
type = "pki"
description = "PKI Secrets Engine"
default_lease_ttl_seconds = 3600
max_lease_ttl_seconds = 86400
}
kubernetes = {
path = "kubernetes"
type = "kubernetes"
description = "Kubernetes Auth Engine"
}
ldap = {
path = "ldap"
type = "ldap"
description = "LDAP Auth Engine"
options = { case_sensitive_names = "true" }
}
transit = {
path = "transit"
type = "transit"
description = "Transit Secrets Engine for Encryption-as-a-Service"
options = {
convergent_encryption = false
}
}
aws = {
path = "aws"
type = "aws"
description = "AWS Secrets Engine"
}
```
}
}
### END FILE: examples/main.tf ###examples/outputs.tf:
### BEGIN FILE: examples/outputs.tf ###
output "mount\_accessors" {
description = "Accessors for the configured Vault mounts"
value = module.vault\_mounts.mount\_accessor
}
### END FILE: examples/outputs.tf ###Nella pratica, un terraform apply su questo esempio apparirà così:
[rramge@ol9 examples]$ terraform apply
[...]
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes module.vault\_mounts.vault\_mount.this\["aws"]: Creating... module.vault\_mounts.vault\_mount.this\["transit"]: Creating... module.vault\_mounts.vault\_mount.this\["kvv2"]: Creating... module.vault\_mounts.vault\_mount.this\["ldap"]: Creating... module.vault\_mounts.vault\_mount.this\["kubernetes"]: Creating... module.vault\_mounts.vault\_mount.this\["pki"]: Creating... module.vault\_mounts.vault\_mount.this\["aws"]: Creation complete after 1s \[id=aws] module.vault\_mounts.vault\_mount.this\["pki"]: Creation complete after 1s \[id=pki] module.vault\_mounts.vault\_mount.this\["transit"]: Creation complete after 1s \[id=transit] module.vault\_mounts.vault\_mount.this\["kvv2"]: Creation complete after 1s \[id=kv-v2] module.vault\_mounts.vault\_mount.this\["kubernetes"]: Creation complete after 1s \[id=kubernetes] module.vault\_mounts.vault\_mount.this\["ldap"]: Creation complete after 1s \[id=ldap] Apply complete! Resources: 6 added, 0 changed, 0 destroyed. Outputs: mount\_accessors = { "aws" = "aws\_e2982916" "kubernetes" = "kubernetes\_6671be50" "kvv2" = "kv\_26a6e11a" "ldap" = "ldap\_8fbb6083" "pki" = "pki\_2d96cba8" "transit" = "transit\_25465e3f" } \[rramge\@ol9 examples]\$
Attivazione tramite interfaccia web
È possibile anche l’attivazione tramite un’interfaccia web. Vault offre una UI web attivabile opzionalmente, molto semplice, più adatta come showcase per presentazioni marketing che per un uso amministrativo in ambienti di produzione di grandi dimensioni.
Non tratterò in questa sede l’interfaccia web - presumo infatti che, in quanto lettore tecnicamente competente ed esperto, comprendiate l’importanza e la necessità di passi di configurazione riproducibili e di automazione in contesti critici per la sicurezza, piuttosto che fare affidamento sui clic del mouse. Imparate invece i comandi CLI e comprendete il valore dell’Infrastructure-as-Code, poiché ciò è fondamentale sia nella pratica che nella preparazione a un esame di certificazione.
Prospettive
Nel prossimo articolo di approfondimento su HashiCorp Vault daremo una prima occhiata alla Secrets Engine Key/Value, prima di esplorarla in profondità.
