Getting Started with HashiCorp Vault

Last Updated on June 11, 2025 by Arnav Sharma

In a world where applications span multiple clouds, environments, and teams, securing sensitive data like API keys, database credentials, certificates, and tokens is a major challenge. Hardcoding secrets into code or storing them in plaintext configuration files is a recipe for disaster.

That’s where HashiCorp Vault comes in. Vault provides a unified interface to securely store, manage, and access secrets across infrastructure. In this post, we’ll break down what Vault is, why it matters, and how its core component—Secrets Engines—works, with a look at some popular examples like KV v2, AWS, and Azure.

What Is HashiCorp Vault and Why Use It?

HashiCorp Vault is an open-source secrets management solution designed to control access to sensitive information. It goes beyond just storing secrets—it enables dynamic access, encryption as a service, and strong identity-based access control.

Why Vault?

Centralized Security: Store all application secrets in one secure location.
Access Control: Enforce who can read/write secrets using ACL policies.
Auditability: Every access request is logged and can be reviewed.
Dynamic Secrets: Generate secrets on-the-fly with automatic expiration.
Encryption Services: Applications can encrypt/decrypt data without having to store the secrets themselves.

Common Use Cases

Automatically generate short-lived database credentials for microservices
Provision temporary AWS IAM credentials for automation tasks
Secure storage of API tokens or certificate keys
Rotate secrets without application restarts

Whether you’re running infrastructure in the cloud, on-premises, or hybrid, Vault is designed to be platform-agnostic and scalable.

Understanding Vault Secrets Engines

Secrets Engines are pluggable components that store, generate, or encrypt secrets. Think of each secrets engine as a specialized backend that supports a specific type of secret management.

Let’s explore three key engines to get started:

1. KV (Key-Value) Secrets Engine v2

The KV engine is Vault’s most basic and commonly used secrets engine, great for storing static secrets like API keys, config values, and passwords. Version 2 (KV v2) supports:

Secret versioning
Soft deletion and recovery
Metadata for secret rotation policies

Example: Enable KV v2

vault secrets enable -path=kv kv-v2

Store a secret:

vault kv put kv/app1 username="arnav" password="SuperSecret123"

Read the secret:

vault kv get kv/app1

Update a secret (creates a new version):

vault kv put kv/app1 password="NewPassword456"

This engine is perfect for applications that need to read static secrets securely at runtime without managing credential expiration.

2. AWS Secrets Engine

This engine dynamically generates AWS credentials such as access keys for IAM users or roles. Instead of hardcoding keys, you can request new ones that expire automatically.

Example: Enable and Configure AWS Secrets Engine

vault secrets enable -path=aws aws

vault write aws/config/root \
    access_key="your-root-access-key" \
    secret_key="your-root-secret-key" \
    region="ap-southeast-2"

Create a role that maps to an IAM policy:

vault write aws/roles/dev-role \
    credential_type=iam_user \
    policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}
EOF

Generate dynamic AWS credentials:

vault read aws/creds/dev-role

The returned credentials are time-limited and automatically revoked when they expire or the lease is revoked.

3. Azure Secrets Engine

Similar to the AWS engine, the Azure Secrets Engine dynamically provisions service principals, reducing the need for long-lived Azure credentials in CI/CD pipelines or automation scripts.

Enable the Azure engine:

vault secrets enable azure

Configure your Azure account:

vault write azure/config \
    tenant_id="your-tenant-id" \
    client_id="your-app-id" \
    client_secret="your-secret"

Define a role:

vault write azure/roles/ci-role \
    application_object_id="app-object-id" \
    ttl="1h"

Generate credentials:

vault read azure/creds/ci-role

These credentials are scoped, short-lived, and generated only when needed—aligning with Zero Trust principles.

ByArnav Sharma