Integrating HashiCorp Vault with Kubernetes

Authenticate Kubernetes pods with HashiCorp Vault to dynamically fetch sensitive credentials rather than relying on static cluster objects.

Authenticating Pods with HashiCorp Vault

In this lesson, you’ll learn how to allow your Kubernetes pods to authenticate directly with HashiCorp Vault to dynamically retrieve secrets, bypassing the need for static, long-lived Kubernetes Secrets.

Moving Beyond Static Secrets

So far, we have managed sensitive data using native Kubernetes Secrets. While useful, these secrets are stored in the cluster’s etcd database, which requires careful management of encryption-at-rest and RBAC. Integrating HashiCorp Vault changes the paradigm: instead of injecting a static secret into a Pod at deployment time, the Pod acts as an identity that "asks" Vault for the secret only when it needs it.

The Authentication Workflow

To achieve this, we use the Kubernetes Auth Method in Vault. When a pod starts, it presents its native ServiceAccount token to Vault. Vault then verifies this token with the Kubernetes API server. If the token is valid and associated with an authorized Role in Vault, Vault issues a temporary, time-limited token to the pod.

The pod uses this token to fetch secrets via the Vault API. Because these secrets are fetched at runtime, you can enable features like dynamic secret generation (e.g., Vault creating a unique, short-lived database user that automatically expires).

Implementation Snippet

To link a Kubernetes ServiceAccount to a Vault policy, you configure a role in Vault that maps the namespace and service account:

vault write auth/kubernetes/role/my-app-role \
    bound_service_account_names=my-app-sa \
    bound_service_account_namespaces=production \
    policies=my-app-policy \
    ttl=24h

By binding the Pod's identity to a specific Vault role, you eliminate the risk of static credentials lingering in the cluster. If the pod is compromised, the temporary Vault token will expire, and the access rights are strictly scoped by the Vault policy, rather than the broad permissions often associated with Kubernetes Secrets. This shift from "pushing" secrets into pods to "pulling" them dynamically significantly tightens your security posture.

Key Takeaway: Instead of storing static secrets in the cluster, use the Kubernetes Auth Method to allow pods to authenticate as themselves and fetch short-lived secrets dynamically from Vault.