// the find
hashicorp/vault-secrets-operator
The Vault Secrets Operator (VSO) allows Pods to consume Vault secrets natively from Kubernetes Secrets.
Vault Secrets Operator syncs HashiCorp Vault secrets into Kubernetes Secrets via CRDs, handling rotation for Deployments, StatefulSets, and ReplicaSets. It covers static secrets, dynamic secrets, and PKI certificates, plus HCP Vault Secrets. This is the official HashiCorp operator, aimed at platform teams running Vault alongside Kubernetes who don't want to deal with the Vault Agent sidecar pattern.
- Covers the full Vault secret surface area: static KV, dynamic secrets, PKI certs, and HCP Vault Secrets all have dedicated CRD types rather than being shoehorned into one generic resource.
- Secret transformation support (templating, filtering fields) via SecretTransformation CRD lets you reshape Vault secret data into whatever format the consuming app expects without touching application code.
- Integration test coverage is genuinely broad — KinD, EKS, GKE, and AKS test paths exist with Makefile targets, including enterprise Vault test scenarios. That's more cloud coverage than most operators bother with.
- Built-in Prometheus metrics and ServiceMonitor template means you can observe sync lag and failure rates without instrumenting anything yourself.
- Still v1beta1 after years of development. The API stability story is unclear — adopting this in production means accepting that field names could change under you.
- The operator writes secret data into Kubernetes Secrets, which means the secrets are in etcd in plaintext unless you've set up envelope encryption separately. The threat model doc exists but the default install does nothing to mitigate this, which will surprise teams who think syncing into K8s Secrets is inherently safer than the Agent sidecar approach.
- Multi-tenancy story requires careful RBAC planning — VaultAuth and VaultConnection resources define Vault connectivity per namespace, but there's no built-in policy to prevent a tenant namespace from referencing a VaultAuth in another namespace if cluster-level RBAC is misconfigured.
- The demo and sample setup relies heavily on running multiple make targets in sequence with undocumented prerequisites (KIND, specific Vault config via shell script), making local onboarding friction higher than it should be for an official HashiCorp project.