Secrets Management: Protecting API Keys and Passwords with Hashicorp Vault

Secrets Management: Protecting API Keys and Passwords with Hashicorp Vault

Hardcoded API keys in application code, plaintext passwords in .env files, and shared credentials are among the most common security vulnerabilities. According to GitGuardian's 2024 report, over 10 million secret leaks are detected on GitHub annually. Hashicorp Vault enables you to centrally manage,

Hardcoded API keys in application code, plaintext passwords in .env files, and shared credentials are among the most common security vulnerabilities. According to GitGuardian's 2024 report, over 10 million secret leaks are detected on GitHub annually. Hashicorp Vault enables you to centrally manage, encrypt, apply access control, and automatically rotate secrets.

Why Is Secrets Management Necessary?

Method Risk Vault Solution
Hardcoded secret Permanent in git history Dynamic secret, runtime injection
.env file Plaintext, no access control Encrypted storage, ACL policies
Shared password No access tracking Audit log, per-user access
Static credential Valid indefinitely if leaked Automatic rotation, TTL

Vault Installation and Basic Usage

terminal
# Write and read secrets
vault kv put secret/myapp/db \
  username="app_user" \
  password="strong_password_32" \
  host="10.0.20.5"

vault kv get secret/myapp/db
vault kv get -field=password secret/myapp/db

Dynamic Secrets and Automatic Rotation

Vault's most powerful feature is dynamic secrets. Instead of static passwords, Vault creates temporary database credentials for each request and automatically deletes them when the TTL (Time to Live) expires.

terminal
# PostgreSQL dynamic secret configuration
vault secrets enable database

vault write database/roles/app-role \
  db_name=myapp-db \
  default_ttl="1h" \
  max_ttl="24h"

# Get temporary credential (valid for 1 hour)
vault read database/creds/app-role

💡 Tip: With dynamic secrets, each application instance receives unique credentials. If a credential leaks, only that instance is affected and it automatically expires when the TTL runs out. This approach minimizes the "blast radius."

For database security, check our MySQL/PostgreSQL security guide. For server security, see our Hardening Checklist. For Zero Trust architecture, review our Zero Trust guide. Build your secure infrastructure with Hosted Cloud cloud servers.

Frequently Asked Questions

Is using .env files instead of Vault sufficient?

.env files are acceptable for small projects but do not provide access control, audit logs, automatic rotation, or encryption. Vault or a similar solution is recommended when multiple services or team members are involved.

What happens if Vault itself is compromised?

Vault encrypts data with AES-256 and cannot be accessed without unseal keys. Unseal keys are distributed to multiple people using Shamir's Secret Sharing. HSM or cloud KMS integration can be used for auto-unseal.

What are the alternatives to Vault?

External Secrets Operator for Kubernetes environments, SOPS (Mozilla) or Sealed Secrets for small projects, and cloud provider KMS services (AWS Secrets Manager, GCP Secret Manager) can be used as alternatives.

I accidentally pushed a secret to Git, what should I do?

Immediately rotate the secret (create a new password/key). Use git filter-branch or BFG Repo-Cleaner to remove it from git history. However, assume the secret may already be compromised and prioritize rotation.

Conclusion

Secrets management is a cornerstone of modern application security. Centrally manage API keys, database passwords, and certificates with Hashicorp Vault, minimize credential leak risk with dynamic secrets, and monitor all access with audit logs.

Secure Infrastructure Management

Build your Vault integration and secure secrets management infrastructure with Hosted Cloud cloud servers.

Explore Cloud Server Plans →
A

Ahmet Yılmaz

Senior Infrastructure Engineer

With over 10 years of experience in cloud infrastructure and DevOps, Ahmet specializes in Kubernetes, Terraform, and high-availability architectures.

Comments coming soon