Enterprise Secret Management on Kubernetes: The Vault Secrets Operator Approach

Platform teams managing Kubernetes often face a security gap: native Kubernetes Secrets aren't designed for enterprise-grade lifecycle management—generation, injection, rotation, and revocation—across clusters and clouds. Centralized secret management becomes essential. HashiCorp Vault is the enterprise standard, and integrating it with Kubernetes can be done via several patterns, each with tradeoffs. This Q&A explores the options, focusing on why the Vault Secrets Operator (VSO) is now the recommended approach for modern secret delivery on Kubernetes and OpenShift.

Why are native Kubernetes Secrets insufficient for enterprise environments?

Native Kubernetes Secrets store sensitive data but lack robust governance. They are base64-encoded, not encrypted at rest by default, and don't support automated lifecycle management—like rotating, revoking, or auditing. In enterprise settings where secrets span multiple clusters, clouds, and external services, relying solely on native Secrets creates vulnerabilities and operational overhead. Teams need centralized policies, identity-based access, and seamless secret rotation without slowing development. Vault fills this gap by providing a platform-agnostic solution that can manage secrets outside Kubernetes as well.

Enterprise Secret Management on Kubernetes: The Vault Secrets Operator Approach — Source: www.hashicorp.com

What are the main Vault integration patterns for Kubernetes?

There are several patterns: Vault Secrets Operator (VSO)—a Kubernetes-native operator that syncs secrets from Vault to Kubernetes Secrets; VSO protected secrets—using a companion CSI driver for in-memory ephemeral volumes; Secrets Store CSI driver—mounts secrets from external stores as CSI volumes; Vault sidecar agent injector—injects a Vault agent container that fetches secrets; and third-party operators—custom controllers. Each pattern has distinct tradeoffs in security, complexity, and developer experience. VSO is the newest and recommended standard due to its native integration and minimal operational overhead.

How does the Vault Secrets Operator (VSO) work?

VSO is a Kubernetes operator that syncs secrets from Vault into native Kubernetes Secrets. You define a custom resource (e.g., VaultSecret) specifying the Vault path and transformations. The operator watches changes and updates the corresponding Secret object. This way, your pods consume secrets via standard Kubernetes mounts or environment variables, with no code changes. VSO handles secret rotation by updating the Secret when the source in Vault changes. It also supports authentication via Kubernetes service accounts, making it seamless in OpenShift environments. This approach reduces complexity and operational burden compared to sidecars or CSI drivers.

What are the advantages of VSO over the Vault sidecar injector?

The Vault sidecar injector adds a container to each pod, which fetches secrets at startup or on rotation. While robust, it increases pod resources, startup time, and operational complexity. VSO eliminates the sidecar by syncing secrets to a Kubernetes Secret that multiple pods can consume. This reduces resource usage and simplifies management. Additionally, VSO provides a native Kubernetes experience—developers only need to reference a Secret, not configure sidecars. For clusters with many pods, VSO scales better and aligns with Kubernetes best practices. The sidecar injector remains an option for legacy workloads, but VSO is now the recommended pattern.

How does VSO compare to the Secrets Store CSI driver?

The Secrets Store CSI driver mounts secrets as volumes from external stores like Vault into pods. It avoids storing secrets in etcd but requires driver installation and per-pod volume configuration. VSO, on the other hand, synchronizes secrets to Kubernetes Secrets, which are stored in etcd (encrypted if enabled). VSO offers simpler setup—no CSI driver needed—and supports automatic rotation of the Secret object. The CSI driver may be preferred for strict security requirements where secrets must never persist in etcd, but VSO provides better developer experience and lifecycle automation for most enterprises. VSO protected secrets (with a companion CSI driver) combines both approaches.

What is VSO protected secrets and when should it be used?

VSO protected secrets extend VSO by using a built-in CSI companion driver that mounts secrets as ephemeral volumes, keeping them out of etcd entirely. This gives the benefits of VSO's declarative management while meeting high-security requirements where secret persistence in the control plane is unacceptable. Use this pattern in regulated environments (e.g., PCI-DSS, HIPAA) where minimizing secret exposure is critical. The setup is similar to VSO but with additional CSI configuration. It offers the best of both worlds: operator-driven automation and in-memory-only secrets delivery.

Why is VSO now the recommended standard for most organizations?

VSO is recommended because it simplifies secret management with a Kubernetes-native operator, reduces resource overhead compared to sidecars, and provides mature lifecycle automation (rotation, revocation). It was developed in partnership between HashiCorp and Red Hat specifically for OpenShift, ensuring tight integration and support. For most use cases, VSO offers the best balance of security, developer experience, and operational simplicity. It does not change how pods consume secrets—they use standard Secrets—so migration is low-risk. As enterprises scale, VSO's centralized control and automation reduce the security gap inherent in native Kubernetes Secrets.

Tags: