Learn Vault - The Secret Management Ecosystem & Tool Comparison

#Introduction

In episode 1, we understood the problem Vault solves: secret sprawl — secrets spreading uncontrollably across source code, .env files, spreadsheets, and chats. We also saw Vault's four capability pillars: centralized storage, dynamic secrets, encryption-as-a-service, and fine-grained access control with audit logging. Now, in episode 2, we'll broaden our view to the secret management ecosystem as a whole — because Vault is not the only tool on the field.

Why does this matter? Because the best architecture decision is never "use the most popular tool," but "use the tool that best fits the problem." An engineer who understands the landscape can argue: "We're single-cloud on AWS, our secrets are few, and the operational budget is tight — AWS Secrets Manager is enough." Or the opposite: "We're multi-cloud, we need dynamic database credentials, and we must pass compliance audits — this is a case for Vault." This ability to choose is what separates an ordinary engineer from one trusted to make architecture decisions.

In this episode we'll cover: first, cloud-native secret managers from AWS, GCP, and Azure; second, open-source tools like SOPS, Passbolt, Vaultwarden, and OpenBao; third, selection criteria — when Vault, when cloud-native, when other tools — complete with a feature comparison table and a sort of decision tree.

#The Secret Management Landscape in Industry

The secret management ecosystem can be mapped into three broad categories. Each occupies a different position on the spectrum between ease and power:

1. Cloud-Native Secret Managers — fully managed by the cloud provider (AWS Secrets Manager, Parameter Store, GCP Secret Manager, Azure Key Vault). Easiest, most integrated, but vendor-locked.
2. Vault-class Platforms — self-hosted, vendor-agnostic, feature-rich (HashiCorp Vault, OpenBao).
3. Specialized Tools — focused on one niche: SOPS for file encryption in Git, Passbolt/Vaultwarden for human passwords, gopass, etc.

This map matters: no single tool answers every need, and a sign of engineer maturity is precisely the ability to place a tool in the right position.

#Cloud-Native Secret Managers

Each major cloud provider has its own secret management service. Their main advantages: nothing to maintain, seamless integration with their respective ecosystems (IaaS, IAM, Kubernetes), and low initial cost. Let's break them down one by one.

#AWS Secrets Manager

AWS's secret management service. It supports scheduled automatic rotation, integration with RDS, and can be accessed from EC2, Lambda, and EKS using IAM roles — without storing secrets in application code.

aws secretsmanager get-secret-value \
  --secret-id api/payment-gateway \
  --query SecretString --output text

Its strengths: managed rotation support, IAM integration, and no server to maintain. Its weaknesses: AWS vendor lock-in, limited encryption-as-a-service and dynamic secret features for non-AWS databases, and per-secret plus per-API-call costs that can balloon at scale.

#AWS Systems Manager Parameter Store

Secrets Manager's simpler, cheaper sibling. Parameter Store focuses on key-value storage (can be plain config, not necessarily secrets). Free for standard parameters, and supports encrypted parameters with KMS.

aws ssm get-parameter \
  --name "/app/production/db/password" \
  --with-decryption --query Parameter.Value --output text

#GCP Secret Manager

A similar service from Google Cloud. It separates secret material (the secret value) from secret versions, so rotation is done by adding a new version. Access is controlled with Google Cloud IAM and it can integrate with GKE, Cloud Run, and Compute Engine.

gcloud secrets versions access latest \
  --secret="api-payment-gateway" --format="value(payload.data)"

#Azure Key Vault

Microsoft Azure's service. Uniquely, Key Vault handles three categories at once: secrets (passwords/tokens), keys (encryption keys for EaaS), and certificates (TLS certificates). Tight integration with Azure AD (Entra ID), Managed Identity, and other Azure services.

az keyvault secret show \
  --name "api-payment-gateway" --vault-name "my-vault" \
  --query value --output tsv

#Cloud-Native Summary

#Open-Source Tools

Beyond the cloud, there's an open-source ecosystem where each tool fills a specific niche. Some are very popular and worth knowing.

#SOPS (Secrets OPerationS)

Mozilla's SOPS is a file encryption tool — not a secret management server. It encrypts secret values inside YAML, JSON, ENV, or INI files, then stores them in Git safely. Its encryption keys can be managed via cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) or local keys (Age, PGP).

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_password: ENC[AES256_GCM,data:Z3VpZGU=,iv:...,tag:...,type:str]
  api_key: ENC[AES256_GCM,data:G4d0xPw=,iv:...,tag:...,type:str]
sops:
  kms:
    - arn: arn:aws:kms:us-east-1:...
      created_at: "..."
      enc: CiC4...

sops --decrypt config.enc.yaml | grep database_password
database_password: G4d0xPw

SOPS's strength lies in its simplicity for GitOps / Infrastructure as Code scenarios: you can review secret changes the way you review normal code. Its weaknesses: no dynamic secrets, no granular per-consumer access, no centralized audit trail, and decryption happens on the machine running sops — not on a centralized server.

#Passbolt & Vaultwarden

These two tools focus on a different category: passwords for humans. Passbolt is an open-source password manager for teams (self-hosted) with sharing and per-user audit features. Vaultwarden is a lightweight, self-hosted reimplementation of the Bitwarden server.

Both are excellent for "team members storing their passwords" needs, but not for application needs: no API for automated apps, no dynamic secrets, and the security model is designed for humans, not machines. Use them for their purpose — don't force them into being "secret management for applications."

#OpenBao: The Community Vault Fork

This is the most relevant for this series. OpenBao is an open-source fork of HashiCorp Vault that was born after HashiCorp changed Vault's license from MPL 2.0 to the Business Source License (BSL) in 2023. OpenBao is maintained by the community and vendor-agnostic, aiming to continue Vault under a fully open-source license.

bao --version
Bao v2.0.1
 
# Every Vault command (vault kv, vault read, etc.) has an equivalent
# with the 'bao' prefix — 100% compatible syntax
bao kv get secret/api/database

Key points you should know:

• Syntax and architecture are identical to Vault — everything you learn in this series applies 100% to OpenBao.
• OpenBao evolves with its own community features (for example, support for additional storage backends).
• Many companies choose OpenBao to avoid the BSL license; others still pick Vault for HashiCorp's commercial support guarantee.

#When to Choose Vault?

Now the big question: among all these tools, when do we choose Vault? The honest answer: not always. Vault carries an operational cost — it's a server that must be maintained, monitored, unsealed, and have its keys rotated. You should only pay that cost if you actually need its capabilities.

#Vault Is the Right Answer When...

1. Multi-cloud or hybrid cloud. You have workloads on AWS and GCP, or cloud and on-premise. Cloud-native secret management is bound to one vendor; Vault is one layer for all.
2. You need dynamic secrets. Database credentials created on-demand with short TTLs — a feature cloud-native secret managers don't natively have.
3. You need encryption-as-a-service. Applications must encrypt sensitive data without holding the keys. Vault Transit is the only one that makes this a centralized, cross-application service.
4. You need automated PKI. Issuing short-lived internal TLS certificates with your own CA, not public certificates from a vendor.
5. You need serious audit & compliance. One source of truth for "who accessed what, when" across all secrets.
6. Insecure by default is not an option. Security teams want one place of control for all company secrets.

#Vault Is NOT the Right Answer When...

1. Single-cloud with few secrets. One app on AWS with 5 API keys? AWS Secrets Manager + IAM roles are more than enough and far cheaper.
2. The need is only human passwords. A small team that needs a shared password store? Passbolt or Vaultwarden are more on target.
3. No operational capacity. Vault needs operators who understand its lifecycle. Teams without security/DevOps staff will struggle; cloud-native "just use it" is more realistic.
4. The need is only config file encryption. All your secrets live in Git-managed files? SOPS + Age/KMS is a far lighter solution.

#Feature Comparison: Vault vs Cloud-Native vs SOPS

To make the decision easier, here's a comprehensive feature comparison table. Notice where Vault excels and where it charges (in the form of operational effort):

#Reading This Table Correctly

• The Dynamic secrets column is the biggest differentiator: only Vault has this capability natively. This isn't a "nice to have" feature — it fundamentally changes the security posture.
• The Multi-cloud column shows another key point: teams running on more than one cloud need a single platform, and cloud-native is vendor-locked.
• The Managed service and Cost model columns are the most common reasons to choose cloud-native: zero operational effort, small cost at small scale.
• SOPS is a special case: not a platform, but a tool — it excels precisely in the Git integration that nobody else has, and fits GitOps workflows.

#A Sort of Decision Tree

If you had to decide today, follow this line of thinking:

#Conclusion

In episode 2, we mapped the entire secret management ecosystem: cloud-native secret managers (AWS Secrets Manager, Parameter Store, GCP Secret Manager, Azure Key Vault), open-source tools (SOPS, Passbolt, Vaultwarden, OpenBao), and the criteria for when Vault is the right choice — plus when it isn't.

Key takeaways to remember:

• No universal tool — each category fills a different need.
• Cloud-native excels at ease and cost, but is vendor-locked and light on advanced features.
• Vault excels at dynamic secrets, EaaS, PKI, multi-cloud, and audit — at the price of operational effort.
• OpenBao is Vault's open-source fork with identical syntax.
• Tool selection must start from needs, not popularity.

Now you understand Vault's position in the ecosystem. In episode 3, we'll dissect Vault's core architecture and security concepts — how the storage backend and Vault Core work, the request flow from client to storage, the initialization and unsealing process with Shamir's Secret Sharing, and the root token risk. This is the most fundamental episode for understanding why Vault is secure — and it will be the foundation for every technical episode that follows. Keep your enthusiasm up, because in episode 3 the mystery of "why Vault needs to be unsealed" will finally be solved!