How to manage Kubernetes secrets with Vault and GitOps

Why managing secrets in Kubernetes is a critical challenge?

Managing sensitive data, such as API keys, database passwords, and SSL certificates, is one of the most delicate tasks in modern system administration. In practice, this means that any mistake in distributing these credentials can expose the entire infrastructure to attackers. In Kubernetes, the default system for storing these data is Secrets, but they come with a major limitation: by default, they are stored in plain text encoded in Base64 within the cluster database, which is far from secure. When we adopt an infrastructure-as-code approach, the problem multiplies because passwords can accidentally end up in code repositories if there is no rigid protection mechanism.

To safeguard these environments, many teams turn to dedicated custody and access control solutions, robustly enhancing infrastructure security. This is where the need arises to separate application code from confidential data, ensuring that the credential lifecycle is managed independently. Furthermore, when we combine this discipline with methodologies on how to manage secrets in production with HashiCorp Vault, we gain an extra layer of defense that prevents accidental leaks and simplifies compliance with rigorous auditing standards.

The role of HashiCorp Vault in automatic credential rotation

HashiCorp Vault is software specifically designed to control access to secrets in a centralized and secure way. Simply put, it works like a highly protected digital safe that validates who is asking for a password before handing it over. One of its greatest advantages is the ability to generate dynamic credentials, meaning passwords created on the fly for a specific purpose and destroyed right after. This solves one of engineers' worst nightmares: the need to remember to change static passwords manually every few months.

In practice, imagine your application needs to access a PostgreSQL database. Instead of embedding a fixed password in the code, Vault creates a temporary database user with strict permissions and sets a short expiration time. When the time expires, the database itself discards the user, and Vault takes care of providing fresh credentials when needed. This automated credential rotation drastically reduces the vulnerability window in case of an attack, as any leaked key will lose validity within minutes.

Integrating GitOps and auditable continuous delivery

The GitOps concept relies on using a Git repository as the single source of truth to define the desired state of infrastructure and applications. Tools like ArgoCD read this repository and automatically apply changes to the Kubernetes cluster, ensuring that what runs in production is precisely what was approved in pull requests. However, a classic dilemma arises: if Git is public or shared, how do you put sensitive passwords there without running serious risks of exposure?

The answer lies in not placing real secrets in the repository, but rather secure references that the cluster can translate into real data at runtime. Tools like the External Secrets Operator connect Kubernetes directly to Vault, fetching secrets dynamically and securely as soon as the application manifest is applied by ArgoCD. This way, we maintain auditable continuous delivery, where every infrastructure modification leaves a clear trail of who approved it and when the change was applied in the production environment.

How to implement secure synchronization step by step

To bring this architecture to life, we need to configure communication between the Kubernetes cluster, the external secrets operator, and the credential vault. Each step below represents a concrete action executed on the infrastructure to ensure that confidential data flows without risk of interception. To complement this implementation in production environments, see our related technical analyses on Why AI hallucinates and how to enforce JSON Schema and Slow API? How to scale connections with WebSockets and gRPC in Go.

1. Install and configure the external secrets operator in your Kubernetes cluster using the Helm package manager with the corresponding command:

   helm repo add external-secrets https://charts.external-secrets.io && helm install external-secrets external-secrets/external-secrets

2. Create a SecretStore resource in Kubernetes to point directly to your Vault server address and define the appropriate authentication method.

   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: vault-backend
   spec:
     provider:
       vault:
         server: 'https://vault.company.local'
         path: 'secret'
         version: 'v2'

3. Define the ExternalSecret telling the operator which secret to fetch from Vault and in what format to save it inside Kubernetes for application use:

   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: app-secrets
   spec:
     refreshInterval: '1h'
     secretStoreRef:
       name: vault-backend
       kind: SecretStore
     target:
       name: my-app-secrets
     data:
       - secretKey: DATABASE_PASSWORD
         remoteRef:
           key: prod/database
           property: password

Conclusion and next operational steps

Adopting HashiCorp Vault alongside GitOps workflows radically transforms the security posture of any organization running Kubernetes. By eliminating static passwords, automating credential rotation, and maintaining complete audit trails, teams gain speed without sacrificing operational peace of mind. It is an architectural investment that quickly pays for itself by preventing costly data leak incidents in production environments.

As your infrastructure evolves, the next natural step is to expand this security policy to other tools and peripheral services, ensuring that the entire continuous delivery chain remains shielded. The secret to long-term success lies in the consistent application of these guidelines across all environments, from local development to large-scale production.