Dynamic Secrets Management in Multi-Cloud Environments with HashiCorp Vault and Kubernetes

The challenge of managing secrets in hybrid clouds

Managing credentials in a single cloud is already a challenge, but the complexity explodes when operating in multi-cloud environments. The fundamental problem lies in persistence: manually created or script-based static passwords often remain valid for months, creating a permanent security loophole if leaked. HashiCorp Vault is the standard tool to solve this, acting as a centralized repository that not only stores secrets but creates them on-demand.

Understanding the concept of ephemeral credentials

In practice, dynamic credentials are secrets created at the moment of request. When an application in Kubernetes needs to access a database, it asks Vault for a temporary credential. Vault communicates with the database, generates a user with limited privileges, and sets an expiration time. After this period, Vault itself revokes the access. This means if someone steals this password, it will be useless in a few minutes, drastically limiting the window of opportunity for an attacker.

Trust architecture with the Kubernetes Auth Method

Kubernetes has a system of Service Accounts, which are identities that each pod (the smallest execution unit in Kubernetes) carries. Vault uses this identity to validate who is requesting secrets. Instead of injecting a fixed access token, we configure Vault to trust the Kubernetes JWT (JSON Web Token). The flow works as follows:

1. The pod sends its Kubernetes JWT to Vault.
2. Vault validates the JWT by querying the Kubernetes API.
3. After validating the identity, Vault issues a short-lived token to the pod.
4. The pod uses this token to request specific credentials, such as a database connection string or a cloud provider API key.

Practical implementation with Secrets Store CSI Driver

Kubernetes allows us to mount secrets directly as file volumes. With the CSI (Container Storage Interface) Driver, integration becomes transparent. The application sees a file inside a folder without needing specific Vault libraries in the code. To configure this integration, we must follow these steps:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-db-creds
spec:
  provider: vault
  parameters:
    vaultAddress: 'https://vault.internal:8200'
    objects: |
      - objectName: 'db-password'
        secretPath: 'database/creds/myapp'

Resilience and multi-cloud considerations

In a multi-cloud scenario, latency and availability are critical. We cannot have a single Vault cluster serving all global regions without a contingency plan. The recommended strategy is using Vault replicators: a primary cluster (usually in a main cloud) syncing data with secondary instances in other providers. This ensures that even if one region goes down, your local applications can still authenticate and retrieve their secrets from the closest regional instance.

Conclusion: Security as automated service

The transition from static to dynamic secrets is a turning point in the operational maturity of any team. By removing the human responsibility of managing and rotating passwords, we reduce the risk of human error and strengthen the system against attacks. Kubernetes and Vault, when operated together, form a robust infrastructure where security is applied programmatically, allowing the engineering team to focus on the product while the system handles identity.

For long-term success, always monitor Vault audit logs. They reveal access patterns and anomalous attempts, acting as a radar to identify strange behaviors before they become incidents. Full automation of the credential lifecycle is the ultimate goal of a modern engineering platform, where the secret is just another disposable resource in the application's lifecycle.