HashiCorp Vault 1.0: secrets management for the cloud era

DataGovern

Integrated compliance platform GDPR + NIS2 + EU AI Act. Cross-Regulation Gap analysis, board-ready dashboard, on-premise.

Discover DataGovern →

Cyber Security

CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.

Discover →

The secrets problem

Modern applications must access dozens of protected resources — databases, external APIs, cloud services, cryptographic keys. Each credential is a secret. Historically these secrets have been poorly managed: hardcoded in code, accidentally committed to Git, distributed by email, stored in unencrypted config files. Credential leaks are a recurring breach category.

HashiCorp Vault — announced in 2015 and reaching version 1.0 on 4 December 2018 — offers a structural response: a central secret store with API, encryption, access control, audit trail, and — a distinctive trait — dynamic secrets generated on demand. MPL 2.0 licence (until 2023, when HashiCorp switches to BSL).

Secrets Engines and dynamic secrets

Vault is not just an “encrypted key-value store”. The key concept is Secrets Engines:

• Key-Value (KV) — versioned static secrets
• Database — generates temporary credentials for PostgreSQL, MySQL, MongoDB, MSSQL, Oracle. The client requests mysql-readonly, Vault creates a MySQL user with random password and a defined TTL (e.g. 1 hour). On expiry Vault deletes it
• AWS / GCP / Azure — generates temporary cloud credentials
• PKI — Vault acts as internal CA, issuing short-lived certificates
• SSH — SSH certificates for hosts or users
• Transit — encryption-as-a-service: applications send data to Vault for encrypt/decrypt, without ever accessing the key
• TOTP — OTP code generation and verification

Dynamic secrets change the model: instead of a permanent DB password that risks leaking, each application receives unique short-lived credentials. A compromise has limited impact.

Auth Methods

Vault separates authentication from authorisation. Supported auth methods:

• Token — Vault’s internal method
• AppRole — for applications (role ID + secret ID)
• AWS/GCP/Azure — IAM-based auth for cloud workloads
• Kubernetes — ServiceAccount JWT as credential
• LDAP/AD, OIDC, GitHub, Userpass
• TLS Certificates, Okta

After auth, HCL policies define what the caller can do. Policies are fine-grained down to the single path/operation.

Architecture

Vault is a single Go binary. It persists state on a storage backend (Consul, etcd, S3, PostgreSQL, file, integrated Raft from 1.4). All data is encrypted with a master key, sealed at runtime — the vault unseal process requires a quorum of unseal keys distributed to custodians.

High availability via Vault HA — multiple instances in cluster, with an active leader.

Ecosystem integration

As of 2018-2019 Vault is deeply integrated with:

• Kubernetes — vault-k8s injector to inject secrets as env vars or files in pods
• Terraform — provider that manages Vault as IaC
• CI/CD — integration with Jenkins, GitLab, GitHub Actions
• Prometheus — metrics endpoint

Open core model

Vault Open Source (MPL 2.0) is free. Vault Enterprise adds: namespaces (multi-tenant), performance replication, disaster recovery, Entropy Augmentation (FIPS), EncryptionSpaces (DR-specific), hardware security module support.

In the Italian context

As of 2018-2019 Italian Vault adoption is rapid in cloud-first infrastructure companies:

• Fintech and digital banks — secrets management for microservices
• Innovative PA — some regional private cloud projects
• Telco — internal PKI certificate management
• ISPs and MSPs — as a component of managed security offerings

References: HashiCorp Vault 1.0 (4 December 2018). MPL 2.0 licence. Secrets Engines (KV, Database, PKI, Transit, AWS/GCP/Azure). Auth Methods (Token, AppRole, Kubernetes, OIDC). Integration with Consul, Terraform, Kubernetes.