HashiCorp Vault + External Secrets Operator: Zero-Trust Secrets Management

TL;DR

• Secrets in Git, classic Kubernetes secrets, and manual processes are no longer sufficient for zero-trust requirements and modern regulations.
• HashiCorp Vault provides the necessary technical foundation for robust, audit-proof secrets management with Secrets Engines, Dynamic Secrets, Encryption as a Service, and detailed audit logs.
• The External Secrets Operator (ESO) connects Vault and Kubernetes: It synchronizes secrets in namespaces in a controlled manner, ensures automatic rotation, and decouples application teams from the complexity of the Vault backend.
• A seamless workflow from Platform Admin → Vault → ESO → Kubernetes → App ensures that credentials for systems like PostgreSQL never end up in Git or unencrypted in clusters.
• ayedo supports organizations in operating Vault and ESO productively and compliantly—from architecture and setup to integration into existing CI/CD and governance structures.

Why Modern Secrets Management is a Core Component of Zero-Trust

Secrets management is not just a security issue but a prerequisite for any serious compliance strategy. Losing access credentials, tokens, or encryption keys can mean losing control over data, systems, and reputation.

With the GDPR (applicable since 25.05.2018), the NIS-2 directive (effective since 16.01.2023, with an implementation deadline of 17.10.2024), and the DORA regulation (effective from 17.01.2025), the pressure to implement security measures in a structured and demonstrable way is increasing. Article 32 GDPR explicitly demands “appropriate technical and organizational measures,” particularly encryption and access control.

In modern, distributed infrastructures—with multiple Kubernetes clusters, GitOps, multi-cloud, and supply chains from third-party providers—it’s no longer enough to “store secrets securely somewhere.” A contemporary concept must:

• be central but multi-tenant,
• offer fine-grained, traceable access policies,
• support automatic rotation and short-lived credentials,
• provide audit-proof logging and auditing capabilities.

HashiCorp Vault in combination with the External Secrets Operator addresses exactly these requirements—without sacrificing developer productivity.

Options Compared: Secrets in Git, Kubernetes Secrets, Vault

Secrets in Git

Storing secrets directly in the Git repository is hardly justifiable today:

• Git is optimized for traceability, not secrecy.
• A committed secret remains in the history.
• Replication in forks, clones, and caches makes deletion practically impossible.
• From a compliance perspective, this is hardly compatible with Article 32 GDPR.

Even with encryption solutions around Git (e.g., SOPS), the challenge remains: Access to Git often also means access to the encrypted artifacts and their key material if governance and key management are not very strictly set up.

Kubernetes Secrets

Kubernetes secrets are an improvement over plaintext environment variables but are conceptually limited:

• By default, they are only stored Base64-encoded in the etcd backend.
• They can be secured with KMS-backed encryption-at-rest but remain cluster-local.
• Rotation usually requires manual processes or individual automation.
• Access control is based on Kubernetes RBAC—good, but not specialized for secrets.

For simple scenarios, Kubernetes secrets are sufficient. In regulated environments with many applications, tenants, or clusters, they reach their limits.

HashiCorp Vault

Vault brings a dedicated secret store with:

• Central management for multiple environments and clusters
• Support for various backends (databases, cloud providers, PKI, identity systems)
• Fine-grained policies with clear responsibilities
• Integrated audit logs for all accesses

In a zero-trust approach, Vault becomes the “source of truth” for all secrets—Kubernetes is then just a controlled consumer via ESO.

HashiCorp Vault in Detail: Engines, Dynamics, and Traceability

Secrets Engines and Dynamic Secrets

Vault abstracts secrets through so-called Secrets Engines. Important examples:

• Key/Value Engines for classic static secrets (e.g., API keys)
• Database Engines for databases like PostgreSQL, MySQL, or SQL Server
• Cloud Engines for temporary IAM credentials with hyperscalers

Dynamic Secrets are particularly relevant here: For a PostgreSQL database, Vault generates short-lived credentials on request, with:

• defined TTL (Time-to-Live),
• optional maximum lifespan,
• automatic revocation after expiration or on demand.

This replaces classic “shared credentials” with temporary, application- or service-specific identities—a significant security gain.

Encryption as a Service

With the Transit Secrets Engine, Vault offers “Encryption as a Service”:

• Applications send data to Vault for encryption and decryption without ever holding keys locally.
• Versioning and rotation of keys are handled centrally.
• Access can be controlled by policy (“may encrypt but not decrypt”).

This not only meets encryption requirements from Article 32 GDPR but also significantly reduces the attack surface for key theft.

Audit Logs and Policies

Every access attempt to Vault—successful or not—can be logged in audit backends like files, syslog, or SIEM systems:

• Who accessed which secret when?
• From which role or service account?
• Which IP or system was involved?

Together with clearly defined policies, a traceable, audit-proof control system is created that provides reliable evidence for NIS‑2 and DORA audits.

External Secrets Operator: Bridge Between Vault and Kubernetes

The External Secrets Operator (ESO) is a Kubernetes operator that connects external secret stores like Vault with the cluster:

• It reads declarative resources (ExternalSecret, SecretStore, ClusterSecretStore).
• It synchronizes the referenced values into regular Kubernetes secrets.
• It automatically updates these secrets when values or versions change in the backend.

This means application teams do not have to work directly with Vault APIs or policies. They simply define which secrets they need, in which namespace, and which backend is responsible. ESO takes care of:

• Authentication against Vault (e.g., via Kubernetes Auth Method),
• Regular refreshing and rotation,
• Error handling and status information within the cluster.

From the pod’s perspective, everything remains the same: It consumes regular Kubernetes secrets. The complex but necessary security and compliance framework lies behind it.

The Workflow: Platform Admin → Vault → ESO → Kubernetes → App

A practical zero-trust workflow might look like this:

1. Platform Admin
   Responsible for central infrastructure like databases, Vault clusters, and Kubernetes base components. They define which systems are managed via Vault and set policies.

2. Vault
   Contains all relevant credentials, whether in KV stores or as dynamic secrets. For databases like PostgreSQL, roles are set up to generate and rotate application-specific credentials.

3. External Secrets Operator
   Runs in the respective clusters and is configured to access the appropriate Vault paths—strictly limited via policies and Kubernetes service accounts.

4. Kubernetes & GitOps
   Application teams define ExternalSecret resources in their Git repositories. GitOps tools like Argo CD deploy these into the cluster. ESO generates the concrete Kubernetes secrets from them.

5. Application
   Uses the provided secrets via environment variables or volume mounts without knowing their origin. Rotation is handled transparently; ideally, a rolling restart occurs automatically when critical secrets change.

In this model, sensitive information never touches Git or CI/CD systems. They remain in Vault and are controlled by ESO into the runtime environments.

Concrete Scenario: PostgreSQL Credentials via ExternalSecret

Consider a PostgreSQL database provided by a platform team—perhaps via CloudNativePG or a managed cloud service.

1. Database Provisioning
   The Platform Admin creates the database and configures a Database Secrets Engine for PostgreSQL in Vault. Roles are defined there to create application-specific users with limited rights and a clear TTL.

2. Vault Configuration
   For each application, there is a Vault path (e.g., per team or service). Policies allow ESO access only to the paths belonging to the respective namespace. Dynamic secrets ensure that credentials are regularly renewed.

3. ESO Integration
   In the Kubernetes cluster, ESO is configured to authenticate against Vault (e.g., via the Kubernetes Auth Method). A SecretStore object describes where Vault is accessible and how authentication works.

4. ExternalSecret by the App Team
   The application team describes an ExternalSecret in their Git repository that:

   • points to the correct Vault path,
   • maps the required fields (username, password, host, port, database name),
   • sets the name of the Kubernetes secret that should later exist in the namespace.

5. Runtime Behavior
   ESO creates the Kubernetes secret, updates it during rotations, and ensures that the application always receives valid credentials. Neither developers nor CI/CD pipelines ever see the plaintext passwords.

This pattern can be applied to many other systems: message brokers, external APIs, cloud resources—anywhere credentials are involved.

Compliance Value: Specifically Addressing GDPR, NIS‑2, and DORA

A Vault+ESO setup helps not only to “somehow” meet regulatory requirements but to demonstrate them in a structured way.

GDPR Art. 32

Article 32 GDPR requires, among other things:

• Pseudonymization and encryption of personal data,
• Ensuring confidentiality, integrity, and availability,
• Procedures for regularly reviewing, assessing, and evaluating effectiveness.

Vault addresses this by:

• Centrally managing, rotating, and audit-proof logging of cryptographic keys.
• Strictly enforcing access to secrets according to the least-privilege principle.
• Making all accesses auditable, including failed access attempts.

ESO complements this by ensuring that secrets only reach the Kubernetes runtime in a controlled manner—without scattering in Git or CI/CD systems.

NIS‑2

The NIS‑2 directive requires operators of critical and important facilities to maintain a high level of cybersecurity, including:

• Identity and access management,
• Risk and incident management,
• Logging and monitoring.

Vault+ESO supports this by:

• Clearly separating identities (service accounts, roles, teams) from permissions and secrets,
• Centrally logging secret accesses,
• Establishing rotation and revocation processes that quickly take effect even in the event of an incident.

DORA

DORA focuses on digital operational resilience in the financial sector. Relevant for secrets management are:

• Protection against credential theft and unauthorized access,
• Ensuring the integrity and availability of systems and data,
• Continuous monitoring and auditing of security measures.

Vault and ESO provide a robust framework to address these requirements effectively.