↓ Skip to main content
Le Site de François
  1. Index/

Vault (HashiCorp Vault)

Security Secrets Key-Management Kubernetes Pki Infrastructure
Table of Contents

HashiCorp Vault is a secrets management platform designed to replace the pattern of static, long-lived credentials scattered across configuration files, environment variables, and CI pipelines with a centralised, policy-enforced, fully audited secrets API. Its core abstraction is that every secret has an identity (a path), an owner (determined by an auth method), a policy (an HCL HashiCorp Configuration Language document granting access to specific paths), and a lease (a TTL after which the secret expires or must be renewed). Nothing in Vault is persistent by default — every access is authenticated, every secret access is logged to an immutable audit trail, and credentials that are no longer needed expire automatically rather than accumulating indefinitely.

Vault’s most architecturally significant feature is its secrets engines: pluggable backends that define how a particular category of secret is generated or stored. The KV engine stores static key-value pairs (API keys, passwords) with optional versioning. The Database engine generates dynamic credentials — short-lived, unique username/password pairs — directly in a target database (PostgreSQL, MySQL, MongoDB), rotated automatically, so no application ever shares a credential or holds one longer than its lease. The PKI engine acts as a certificate authority: it issues X.509 certificates on demand with configurable TTLs (minutes to hours rather than years), eliminating the manual CSR/approval cycle and making certificate rotation a non-event. The Transit engine provides encryption-as-a-service — applications encrypt and decrypt data by calling Vault rather than holding a key themselves, and key rotation happens inside Vault without re-encrypting all data at once. On startup, Vault is sealed: its encrypted storage is inaccessible because the master key is split into shards using Shamir’s Secret Sharing, requiring a quorum of key holders to unseal it. In production, auto-unseal via a cloud KMS (AWS KMS, Azure Key Vault) or an HSM (via PKCS#11) replaces the manual quorum, allowing Vault to restart without operator intervention while the master key remains hardware-protected.

Vault integrates with Kubernetes through three complementary patterns, each answering a different question: how to configure Vault for the cluster, how to sync secrets into native Secret objects, and how to deliver secrets as files inside pods. Platform teams often use Vault Config Operator (VCO) or Terraform for the first layer, then VSO or the Agent Injector for workloads. VSO and the Agent Injector are both HashiCorp-supported; VCO is the community redhat-cop/vault-config-operator project (common on OpenShift for GitOps Vault admin).

Vault Config Operator (VCO)Vault Secrets Operator (VSO)Vault Agent Injector
Primary roleDeclaratively configure Vault (auth mounts, K8s roles, secret engines, policies)Sync Vault secrets into native Kubernetes Secret objectsInject Vault secrets as files in annotated pods
Vault API useAdmin / provisioningRead secrets for workloadsRead secrets per pod
Typical consumerPlatform / security teamApplication teams, GitOpsApps that read config from disk
Pod changesNone (cluster-level CRDs)None (standard Secret refs)Annotations + init/sidecar containers
Secrets in etcdOnly if using VaultSecret CR (overlap with VSO)Yes — materialised Secret objectsUsually no — files on a shared volume
Relation to ESOOrthogonal (config vs consumption)Vault-only; similar consumption model to ESOOrthogonal; file-based alternative
MaintainerCommunity (Red Hat COP)HashiCorp (supported)HashiCorp (supported)

Choose VCO (or Terraform) to set up Kubernetes auth, paths, and roles before apps consume secrets. Choose VSO (or ESO) for standard envFrom / secretKeyRef workflows at the cost of secrets in the control plane datastore. Choose the injector when file-based delivery and keeping secret material out of the Kubernetes API matters.

In the confidential computing stack, Vault occupies a different niche from Trustee: Trustee gates secret release on TEE hardware attestation evidence (a TDX Quote or SEV-SNP report) and is purpose-built for the CoCo threat model where the infrastructure is untrusted; Vault gates secret release on identity and policy (Kubernetes service account, AWS IAM role, AppRole) and is purpose-built for the conventional infrastructure threat model where the platform itself is trusted. The two are complementary rather than competing — a CoCo workload might use Trustee to bootstrap a Vault token inside a TEE, then use Vault for all subsequent secret management — and both sit above an HSM when the highest assurance key storage is required.

Additional Information
#

Related

KMS v2 (Kubernetes KMS Provider v2)

Kubernetes Security Encryption Etcd Kms Secrets Key-Management
KMS v2 (Kubernetes KMS Provider version 2) is the stable (GA since Kubernetes 1.29, KMS v1 deprecated in 1.28 and disabled by default in 1.29) mechanism for encrypting the contents of the Kubernetes etcd datastore at rest using an external key management service. Without encryption, Kubernetes Secrets stored in etcd are base64-encoded — trivially decodable by anyone with read access to the etcd data files or a snapshot. With KMS v2 enabled, resources written to etcd — Secrets, ConfigMaps, and any other API objects selected by the EncryptionConfiguration — are encrypted before being persisted, using a unique per-object key derived locally. The envelope encryption scheme means those per-object keys are never stored in plaintext: only their encrypted form lives in etcd, and only the external KMS holds the wrapping key. The encryption configuration is declared in a file referenced by the API server’s --encryption-provider-config flag, with kms: apiVersion: v2 selecting the KMS v2 code path, and endpoint: unix:///path/to/plugin.sock pointing at the plugin’s Unix domain socket.

ESO (External Secrets Operator)

Kubernetes Secrets Security Operator Gitops Cncf
External Secrets Operator (ESO) is a CNCF incubating project that bridges the gap between Kubernetes-native secrets and enterprise secret management backends. Its premise is that native Kubernetes Secrets — base64-encoded values stored in etcd — are not adequate as a primary secret store: they offer no encryption at rest by default, no access audit trail, no versioning or rotation lifecycle, and no single source of truth across multiple clusters. Rather than replacing Kubernetes Secrets as a consumption mechanism (applications still mount them as environment variables or files in the familiar way), ESO replaces etcd as their source of authority, pulling the real values from a backend that does provide those properties and keeping the Kubernetes Secret as a synchronised, ephemeral projection.

HSM (Hardware Security Module)

Security Hardware Cryptography Key-Management Pki Fips
A Hardware Security Module (HSM) is a purpose-built, tamper-resistant hardware device that holds cryptographic keys and performs cryptographic operations — signing, encryption, decryption, random number generation — entirely within its own protected boundary. The defining property is that private keys generated inside an HSM never exist in plaintext outside it: operations that need the key are sent into the HSM and the result is returned, but the key material itself cannot be extracted. This property is enforced both logically (the firmware refuses export in plaintext) and physically (the device detects and responds to tampering by erasing key material before an attacker can read it). HSMs come in several physical forms: network-attached appliances (rack-mounted devices accessed over the network by many clients), PCIe cards (embedded in a server), and compact USB devices for lower-throughput use cases like protecting CA root keys offline.