HashiCorp Vault: Secure Secret Management in Applications

HashiCorp Vault is the standard solution for storing, access controlling and auditing secrets, passwords, tokens, SSH keys, certificates. In 2025, Vault integrates with CI/CD pipelines, Kubernetes clusters, and serverless platforms, offering a policy-centric security model. For those who lead infrastructure, the decision to adopt it is, in essence, the decision to take credentials from scattered configuration files and environment variables and place them under a single control and audit regime.

Why use Vault?

Five properties support the adoption case. Centralization establishes a single point of truth for all secrets, eliminating scattered copies. encryption at rest and in transit, with keys managed by Vault itself, ensures that data remains unusable outside the authorized context. Granular access policies control who accesses what, through which path, and for how long. Autorotate generates temporary credentials for banks, cloud and services, shortening the exposure window for any credential. And the complete audit records each reading and writing with date, time and identity, an essential condition for investigating incidents and proving compliance.

Typical architecture

A typical implementation is organized into four elements. The Vault server operates in high availability mode, supported by integrated storage or Consul, so that the unavailability of the secret manager never brings down the applications that depend on it. authentication methods define how each client proves who they are, AppRole for applications, native Kubernetes authentication for clustered loads, as well as options like GitHub and TLS. The secrets engines determine how secrets are stored or generated: the key-value engine for static secrets, and dynamic engines for databases, AWS, SSH and PKI. And policies, written in HCL, are applied to tokens or entities, translating the principle of least privilege into concrete rules.

The general flow is as follows: an application authenticates to the Vault (for example, via AppRole) and receives a short-term token; With this token, you read the secrets you are entitled to, bank credentials, cloud keys, always within the limits of your policy. Loads running on Kubernetes authenticate using the cluster's native method. Every interaction generates an audit record, which can be forwarded to a SIEM for correlation. Instead of credentials hard-coded, applications now obtain them on demand, with an expiration date and traceability.

Configuring the Vault

In a test environment, Vault can run in development mode, which runs on an ephemeral server with a root token already available and the ready-to-use key-value engine, useful for quick experimentation, never for production. In production, initialization is done deliberately, with the operator init process generating the unseal keys and initial root token, and with storage configured in high availability mode. The difference between the two modes is essentially the difference between convenience and real security.

Authentication via AppRole

AppRole is the recommended method for authenticating applications. The idea is to create a role associated with a policy and validity limits, token lifetime, maximum time, secret identifier validity. The application receives two factors: a RoleID, which identifies the role, and a SecretID, dynamically generated, which works as a usage credential. With this pair, the application obtains a short-term token to operate. The separation between the two factors allows them to be distributed through different channels, reducing the risk of simultaneous compromise.

Reading secrets

Once authenticated, the application points to the Vault server address and reads the secret in the path it has access to, receiving, for example, the set of configuration keys stored for that service. The simplicity of the reading is on purpose: the complexity is concentrated in politics and authentication, not in the consumption of secrets.

Integration with Kubernetes

In Kubernetes, the most used pattern is the Vault Agent Injector, which injects secrets as sidecar containers. Configuration is done by notes in the pod's manifest, specifying that injection is enabled, which role to use and which secrets to mount. The injector creates, within the pod, temporary files with the requested secrets, which the application reads as if they were local files. The developer does not need to embed authentication logic in the application code, the platform takes care of this transparently.

Access policies

Policies are the heart of the Vault security model. Written in HCL, they grant specific abilities to specific paths. A well-designed policy for an application grants, for example, only read-only access to that app's secrets and the ability to query the token itself, nothing more. This rigor is the practical translation of least privilege: each identity sees only what is strictly necessary for its function, and any attempt to access outside this scope is denied and recorded.

Automatic rotation of database credentials

One of Vault's most valuable features is generating on-demand, short-validity bank credentials. The connection with the bank is configured and a role is defined that describes how to create temporary users, with standard and maximum lifetimes. When an application requests access, Vault creates a user in the bank valid for that period and discards it when it expires. The result is that there are no longer static bank credentials circulating, each access uses an ephemeral credential, which drastically reduces the impact of a possible leak.

Auditing and logging

Auditing is enabled through an audit device, which can record to a file or send to syslog. Each record contains the request identifier, authentication data, the path accessed and any errors. These logs are the basis for investigating incidents and demonstrating compliance, without reliable auditing, access control becomes an unverifiable promise.

Good security practices

Five practices support secure Vault operation. The first is to require mutual TLS between clients and server, guaranteeing authenticity on both ends. The second is to segregate namespaces by environment, isolating development from production. The third is to apply least privilege to all policies, without convenience exceptions. The fourth is to periodically rotate the root token, treating it as a very high-risk credential. And the fifth is to maintain consistent backups of the storage so that the loss of the secret manager does not become a catastrophic incident.

Deployment checklist

A well-conducted deployment usually follows this order: install Vault in high availability mode; configure TLS and certificates; enable the necessary authentication methods (AppRole, Kubernetes); create the secret engines (key-value, database, AWS); define granular access policies; activate the audit device; test automatic credential rotation; document the token obtaining flow; and integrate Vault into the CI/CD pipeline.

Conclusion

HashiCorp Vault provides a robust framework for managing secrets, reducing the attack surface and facilitating compliance. By adopting strong authentication, least privilege policies, and full auditing, an organization protects critical credentials and automates secret rotation in modern environments, transforming secret management from blind spot to auditable control.

Do you already use Vault in your stack? Share your tips and challenges in the comments!