Kubernetes integrations comparison

HashiCorp Vault provides three different integrations to help Kubernetes workloads consume secrets from Vault without modifying application code. Each integration has unique characteristics that make it suitable for different use cases.

Use the information below to compare the available integrations and choose the right solution for your needs.

Features at a glance

Feature	Vault Secrets Operator	Vault Secrets Store CSI provider	Vault Agent Injector
Supported secret types	Static/KV, PKI, Dynamic, Database, AppRole secret IDs	All	All
Supported auth methods	K8s, AppRole, GCP, AWS, JWT	K8s, JWT	K8s, other auto-auth methods
Storage model	K8s Secrets (default) Ephemeral volumes (CSI driver)	Temporary K8s Secrets or ephemeral volumes	Ephemeral volumes
Kubernetes-native	Yes	Yes	No
Secret data persistence	Persisted in `etcd` (default) Ephemeral (CSI driver)	Temporarily persisted or ephemeral	Ephemeral
Secret data templating	Yes	No	Yes
Requires Vault for Pod autoscaling	No (default) Yes (CSI driver)	Yes	Yes
Secret sharing between applications	Yes	Yes	No

Vault Secrets Operator

The Vault Secrets Operator synchronizes secrets from Vault to native Kubernetes Secrets. Vault Secrets Operator reconciles Custom Resource Definitions (CRDs) to sync secret data from Vault to Kubernetes Secrets that applications can consume using standard Kubernetes patterns. Vault Enterprise users can also configure Vault Secrets Operator to run a CSI driver to bypass Kubernetes Secrets and mount secrets directly from Vault to application containers as volumes.

Best for: Teams who prefer native Kubernetes workflows and want the option of writing secrets to persistent cluster storage or ephemeral volumes.

Vault Secrets Store CSI provider

The Vault Secrets Store CSI provider uses the vendor-neutral Secrets Store CSI driver to mount secrets from Vault as ephemeral volumes. You can deploy Vault Agent alongside the provider to manage caching and renewals.

Best for: Organizations using multiple secret stores in addition to Vault, or those who prefer vendor-neutral CSI standards.

Vault Agent Injector

The Vault Agent Injector injects Vault Agent sidecar containers into Pods. The Agent containers authenticate with Vault and render secrets to a shared memory volume for consumption by application containers.

Best for: Applications that want to reference multiple Vault secrets in one template or need a wider array of auth methods.

Use case recommendations

The appropriate integration for your environment depends on the applicable security policies, secret data governance, ease of use requirements, and system availability guarantees.

Limitation	Vault Secrets Operator	Vault Secrets Store CSI provider	Vault Agent Injector
Requires privileged Pod access	No, except with CSI driver	Yes	No
Flexibility in how to consume secrets	Yes	Yes	No
Low resource consumption (I/O, CPU, Memory)	Yes	Yes	No
Secret data limited to ephemeral volumes	No	No	Yes
Pod Autoscaling dependent on Vault availability	No, except with CSI driver	Yes	Yes
Personas easily separated via K8s RBAC policies	Yes	No	No

Performance considerations

Performance characteristics vary significantly between integrations based on their architectural patterns.

Vault Secrets Operator - Lowest load due to CRD-specific connections and cluster-local secret caching. Single manager for an entire cluster.
Vault Secrets Operator with CSI driver - Lower load due to one Vault connection pool per Node, with client caching.
Vault Secrets Store CSI provider - Higher load due to per-Pod connections.
Vault Agent Injector - Highest load due to per-Pod connections and sidecar pattern.

Vault Secrets Operator - Lowest consumption due to one client process needed per Kubernetes cluster. Low to moderate consumption if using the CSI driver, due to one driver needed per Node.
Vault Secrets Store CSI provider - Low to moderate consumption due to one client process needed per Node.
Vault Agent Injector - Higher consumption despite tunable resource allocation as each Pod requires a dedicated client process as a sidecar container.

Migrating to Vault Secrets Operator

To migrate to Vault Secrets Operator from the other Kubernetes integrations:

Create CRDs for each relevant secret type, such as VaultStaticSecret, VaultDynamicSecret, VaultPKISecret, or CSISecrets. Refer to the API reference for configuration details. Note that the Vault Secrets Operator CSI driver only supports KV secrets and AppRole secret IDs.
Update your applications to use Kubernetes Secrets.
To migrate from Vault Agent Injector, you may need to update your secret templates as the Go templating in Vault Agent Injector may not work with the Vault Secrets Operator SecretTransformation resource out of the box.
To use direct secrets you also need:
A Vault Enterprise license.
Updated Pod specifications that reference CSI volumes.

Next steps

For detailed implementation guidance, refer to the documentation for your chosen integration: