HashiCorp Vault: The Reference Architecture for Centralized Secrets Management & Encryption

TL;DR

In a multi-cloud world, security is not about location, but identity. Relying on cloud-specific tools like AWS Secrets Manager fragments your security strategy and creates blind spots. HashiCorp Vault is the industry standard to organize this chaos. It acts as a central broker of trust: managing not only static secrets but generating dynamic credentials “Just-in-Time” and providing Encryption-as-a-Service to protect sensitive data before it ever lands in a database.

1. The Architectural Principle: Identity-based Security

Traditional security was based on IPs and networks (firewalls). In Kubernetes, where pods come and go, this no longer works.

Vault establishes identity as the new security boundary.

• Universal Auth: Whether it’s a Kubernetes pod, an AWS EC2 instance, or a developer via LDAP – Vault authenticates the request against trusted sources (e.g., Kubernetes Service Accounts).
• The Broker: Only after successful authentication does Vault exchange this identity for a short-lived token that grants access to precisely defined secrets. The application no longer needs to store static passwords in config files.

2. Core Feature: Dynamic Secrets (The End of Static Passwords)

The greatest risk in IT is long-lived credentials (“Rotation Fatigue”). A database password valid for 3 years is a security risk.

AWS Secrets Manager can rotate, but Vault goes a step further with Dynamic Secrets.

1. A service (e.g., Order-Service) asks Vault: “I need access to the Postgres database”.

2. Vault connects to the database, creates a new user with a password at that moment (e.g., v-token-order-123).

3. Vault returns these credentials to the service.

4. After the time expires (TTL, e.g., 1 hour), Vault automatically deletes the user.

   The result: There is no “master password” that can be stolen. Credentials exist only as long as they are needed.

3. Encryption as a Service (Transit Engine)

Developers should not program cryptography (“Don’t roll your own crypto”). Mistakes in implementing AES are pre-programmed.

Vault offers the Transit Engine.

Applications send data (e.g., credit card numbers) to the Vault API and receive the encrypted ciphertext back. Only Vault holds the key. The application only stores the ciphertext in the database. Even if the database is stolen (“SQL Dump”), the data is useless because the key remains secure in Vault.

4. Operational Models Compared: AWS Secrets Manager/KMS vs. ayedo Managed Vault

Here it is decided whether your security is tied to a provider or if you operate a global security platform.

Scenario A: AWS Secrets Manager & KMS (The Fragmented Solution)

AWS offers solid tools, but they are island solutions.

• Cost Scaling: AWS Secrets Manager costs $0.40 per secret per month plus API fees. In a microservices architecture with thousands of dynamic secrets, this quickly becomes expensive.
• No Multi-Cloud: KMS keys from AWS cannot decrypt data in Azure or on-prem. You need to build separate security concepts for each environment.
• Static: The focus is on storing secrets, not on dynamic generation. True “Just-in-Time” access is complex to build with AWS native tools.

Scenario B: HashiCorp Vault with Managed Kubernetes by ayedo

In the ayedo app catalog, Vault is the central fortress.

• Unified Interface: One API, one workflow. Whether the app runs on AWS EKS or in the local data center – it always communicates with Vault.
• Agent Injector: Vault integrates natively into Kubernetes. A “sidecar” container injects secrets directly into the pod’s filesystem or as environment variables. The application often doesn’t even need to know that Vault exists.
• Cost Control: Since Vault runs as software in your cluster, you pay for the infrastructure, not per secret. You can generate millions of dynamic credentials without the bill exploding.

Technical Comparison of Operational Models

FAQ: Vault & Security Strategy

Isn’t Vault extremely complex to operate?

Yes, Vault is considered one of the most complex tools in the Cloud-Native Stack (“Day 2 Operations”, Unsealing, High Availability). That’s precisely why it’s part of the managed stack by ayedo. We take care of auto-unsealing (automatic unlocking after restart), backups, and upgrades, so you can consume Vault simply as an API.

Why isn’t the External Secrets Operator (ESO) enough?

ESO (see separate article) is great for synchronizing existing secrets from A to B. However, Vault is a Secret Engine. ESO cannot dynamically create database users or encrypt data (Transit). In many architectures, we use both: Vault as the source of truth and ESO to distribute Vault secrets into namespaces.

What happens if Vault fails?

Since Vault is at the center of all applications, it is a critical component. In the ayedo stack, Vault is therefore operated in high-availability (HA) mode with a Raft storage backend. Multiple instances run distributed across nodes (and AZs). If the leader fails, a standby node immediately takes over.

Can Vault also issue certificates (PKI)?

Yes. Vault can function as a full Certificate Authority (CA). It can issue short-lived TLS certificates for microservices, VPNs, or SSH access. This makes it a powerful alternative to AWS Private CA (which is very expensive).

Conclusion

Security should not be an afterthought or an island solution. Using AWS Secrets Manager solves a storage problem. Using HashiCorp Vault solves an architectural problem. Vault enables “Zero Trust” right to the core of the application, regardless of which cloud it floats on. With the ayedo managed stack, you get this powerful security infrastructure ready to operate – the “Fort Knox” for your digital assets, without the operational burden of building the vault.