Marcio Cunha

Secrets Management and Automated Credential Rotation in Kubernetes

Learn how to integrate HashiCorp Vault into Kubernetes clusters using Sidecar Injectors to ensure dynamic injection and automated credential rotation without restarting applications.

Marcio Cunha•5 min
Also available in:EspañolPortuguês
Summary
  • Sidecar secret injection eliminates the need to store static credentials inside configuration files and code repositories.
  • Automated rotation drastically reduces the attack surface by strictly limiting the lifespan of database passwords and tokens.
  • The use of auxiliary pods ensures that the lifecycle of credentials is managed in isolation from the core microservice business logic.
  • Identity-based policies prevent master key leakage and guarantee precise auditing of access to critical infrastructure resources.
  • Implementation requires resilience planning so temporary outages in the central vault do not bring down production workloads.

The Challenge of Credential Management in Distributed Systems

Managing passwords, API keys, and certificates across modern microservices architectures is one of the toughest operational hurdles faced by engineering teams. In practice, this means a distributed system must supply sensitive credentials to hundreds of applications without exposing those secrets in plain text within source code repositories or static configuration files. When working with Kubernetes, the native mechanism known as Secrets has significant security limitations, as its default Base64 encoding represents mere obfuscation rather than actual encryption at rest by default.

To solve this structural problem, organizations turn to dedicated secrets management solutions, with HashiCorp Vault reigning as the dominant tool in enterprise infrastructure. Vault centralizes access control, enforces strict least-privilege policies, and generates on-demand credentials for databases, cloud services, and external APIs. However, connecting an application directly to the vault requires changes to source code and authentication logic, which creates unwanted coupling and hinders the portability of legacy systems into containers.

Sidecar Injector Architecture: How It Works in Practice

The most elegant and resilient approach to delivering secrets into a Kubernetes cluster without modifying application code is the use of Sidecar Injectors. In practice, a sidecar is an auxiliary container running alongside the main container inside the same Pod, sharing the same network space and local storage volumes. When an application is deployed to the cluster with specific annotations, Vault's mutating webhook intercepts the creation object and automatically injects this auxiliary container along with an in-memory volatile volume known as an emptyDir.

This auxiliary container communicates directly with Vault using the Pod's Kubernetes identity, authenticates securely, and fetches the required credentials even before the main application starts up. Next, the retrieved secrets are written to a file inside the shared in-memory volume, ensuring no sensitive data touches the persistent hard drives of the cluster nodes. For the primary microservice, reading a dynamically generated credential simply boils down to opening a local file at the expected path, exactly as if the password were hardcoded, but with the added benefit of being ephemeral and fully managed.

Practical Implementation with Configurations and Templates

To put this architecture into operation, we need to configure Vault's Kubernetes authentication method and apply the correct annotations to the application's deployment manifest. The following example demonstrates a Deployment manifest configured to request automatic injection of database credentials using Vault agent annotations.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: financial-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: financial-app
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "financial-app-role"
        vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/readonly"
        vault.hashicorp.com/agent-inject-template-db-creds: |
          {{- with secret "database/creds/readonly" -}}
          export DB_USER="{{ .Data.username }}"
          export DB_PASS="{{ .Data.password }}"
          {{- end -}}
      labels:
        app: financial-app
    spec:
      containers:
        - name: web
          image: my-company/financial-app:v1.2.0
          ports:
            - containerPort: 8080

In this manifest, annotations starting with vault.hashicorp.com instruct the cluster webhook to inject the agent. The template annotation uses Go templating to format the retrieved secret directly into environment variables or configuration files consumed by the main process. This means that if the database password expires or is rotated, the Vault agent will update the local file at runtime, allowing modern processes to read the new credential without service downtime.

Automated Rotation and Ephemeral Lifecycle

The major operational differentiator of advanced secrets management lies in automated rotation, which eliminates the use of long-lived passwords. In legacy systems, credentials often last for years until someone decides to change them manually, increasing the risk associated with accidental leaks in logs or public repositories. With Vault configured to communicate directly with database engines like PostgreSQL or MySQL, each credential request generates a temporary user with restricted permissions and a strict expiration date enforced by the system.

When the token or credential lifetime expires, Vault itself revokes access in the underlying database, while the agent injected into the Pod renews the secret in the background or triggers a graceful reload of the application. In practice, this requires microservices to be designed to handle periodic connection credential replacement without losing the state of active transactions. The security payoff vastly outweighs the architectural complexity, because even if a credential is intercepted on the network, its validity expires in a matter of minutes.

Failure Mitigation and Resilience Considerations

Adopting an architecture based on centralized vaults and sidecar injection introduces new operational dependencies that must be handled rigorously to prevent system outages. If the Kubernetes cluster temporarily loses connectivity with the Vault server during a Pod restart, the startup process may fail, preventing the main container from launching correctly. To mitigate this risk of cascading failure, it is essential to configure robust caching policies in the Vault agent and establish proper retry strategies in infrastructure manifests.

Another critical aspect lies in actively monitoring resource consumption across cluster nodes, as the continuous execution of extra agents in every Pod increases memory and processing overhead. Platform engineers must properly size resource limits and requests for injected sidecars, ensuring that traffic spikes in the vault do not compromise business workload stability. With a well-dimensioned topology monitored by observability tools, the infrastructure achieves a mature level of automated security, shielding critical data against unauthorized access.

Final Thoughts on Secrets Governance

The journey toward a secure cloud-native infrastructure requires abandoning old operational habits, such as using static configuration files and credentials with indefinite lifespans. Combining Kubernetes with HashiCorp Vault and Sidecar Injectors represents the state of the art in reliability and security engineering, allowing development teams to operate with speed without sacrificing compliance rigor. By automating rotation and isolating the credential lifecycle, organizations transform security from a bureaucratic hurdle into a continuous enabler of innovation and operational stability.