Skip to content
Learni
View all tutorials
DevOps & Infrastructure

How to Master HashiCorp Vault in Production 2026

18 minADVANCED
SécuritéKubernetesHashiCorp Vault
Lire en français

Introduction

HashiCorp Vault is the industry standard for centralized enterprise secret management. In 2026, compliance requirements and automatic rotation demand a robust architecture with distributed storage and dynamic policies. This tutorial guides you step-by-step to a production-grade deployment with Raft, mutual TLS, and Kubernetes integration. You will learn to prevent secret leaks while automating their lifecycle.

Prerequisites

  • Kubernetes 1.28+ with Helm 3.12+
  • HashiCorp Vault 1.17+
  • Advanced knowledge of RBAC and TLS
  • Cluster with at least 3 nodes for Raft quorum
  • cert-manager installed for certificates

Deployment with Helm and Raft

vault-values.yaml
global:
  enabled: true
server:
  standalone:
    enabled: false
  ha:
    enabled: true
    raft:
      enabled: true
      setNodeId: true
  dataStorage:
    enabled: true
    size: 10Gi
  extraEnvironmentVars:
    VAULT_LOG_LEVEL: "info"
ui:
  enabled: true
  serviceType: "ClusterIP"

This values file enables HA mode with Raft storage for high availability. The quorum requires at least 3 pods to tolerate a failure.

Helm Chart Installation

terminal
helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault -n vault --create-namespace -f vault-values.yaml
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=vault -n vault --timeout=300s

The command deploys Vault in HA mode. Wait for the pods to be ready before initializing the cluster.

Initialization and Unsealing

init-vault.sh
#!/bin/bash
kubectl exec -n vault vault-0 -- vault operator init -key-shares=5 -key-threshold=3 > vault-init.txt
kubectl create secret generic vault-keys -n vault --from-file=vault-init.txt

Initialization generates 5 unseal keys of which 3 are required. Store them immediately in an encrypted Kubernetes secret.

Advanced Policy Configuration

app-policy.hcl
path "secret/data/app/*" {
  capabilities = ["create", "read", "update", "delete"]
}
path "database/creds/app-role" {
  capabilities = ["read"]
  allowed_parameters = {
    "ttl" = ["1h", "2h"]
  }
}

This HCL policy restricts access to application secrets and dynamic database credentials with controlled TTL.

Enabling Dynamic Secrets Engines

enable-engines.sh
vault secrets enable -path=secret kv-v2
vault secrets enable database
vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-role" \
  connection_url="postgresql://{{username}}:{{password}}@postgres:5432/app"

Enables KV v2 and the database engine to generate temporary credentials with automatic rotation.

Best Practices

  • Always use policies with strict TTLs and least privilege
  • Store unseal keys in an HSM or external manager
  • Enable audit logging to a SIEM
  • Implement mutual TLS encryption between agents and Vault
  • Regularly test Raft snapshot restoration

Common Errors to Avoid

  • Forgetting to encrypt unseal keys (risk of total leakage)
  • Using a single node in production (loss of quorum)
  • Neglecting authentication token rotation
  • Configuring overly permissive secret paths without auditing

Further Reading

Discover our advanced training on infrastructure security: https://learni-group.com/formations. Deepen Vault integration with SPIRE and serverless workloads.