Introduction to the VSO

If you’re using HashiCorp Vault and managing workloads in Kubernetes, you’re going to want to know about the Vault Secrets Operator—or VSO, for short.

HashiCorp has made it clear how important this tool is: it’s now part of the Vault Associate certification exam. That says a lot about how widely it’s being adopted across the industry.

Note: This content is from my HashiCorp Certified: Vault Associate (w/ Hands-On Labs). Make sure to check it out for additional content on HashiCorp Vault.

So, What Is the Vault Secrets Operator?

In simple terms, the Vault Secrets Operator is a Kubernetes-native controller that syncs secrets from Vault into Kubernetes—without adding Vault logic to your apps.

Your application teams don’t need to know anything about Vault. They can just pull secrets from Kubernetes Secrets like they always have, and VSO handles all the heavy lifting in the background.

I remember the first time I saw this in action and thought, “Wow, I wish I had this when I was writing all those Vault Agent sidecar configs!” It’s a much cleaner, more declarative way of working with Vault and Kubernetes.

Why Use the VSO?

Managing secrets in Kubernetes can be complicated—especially when every app has to authenticate to Vault, fetch secrets, and deal with rotations or renewals. VSO makes this much easier:

• ✅ Syncs secrets one-way from Vault to Kubernetes (Vault stays the source of truth)
• ✅ Keeps apps Vault-unaware (no authentication logic needed in the pod)
• ✅ Uses Kubernetes Secrets as the delivery layer

How the VSO Works

Once installed, the VSO behaves like any other Kubernetes controller.

Here’s the general workflow:

1. You write a CR (Custom Resource) that describes what secret to pull from Vault.
2. The operator reads that CR and fetches the secret.
3. It then creates or updates a Kubernetes Secret in your app’s namespace.
4. Your application reads the secret from Kubernetes—with no changes to your code.

This approach means your dev teams don’t need to know anything about Vault—everything just works through Kubernetes.

Core Capabilities of the Vault Secrets Operator

Here’s what really makes VSO shine:

• 🔁 Supports multiple secret sources: KV, dynamic creds, PKI certs—you name it.
• 🛠️ Automatic drift detection & remediation: Keeps Kubernetes secrets up to date if things change in Vault.
• 🚀 Pod lifecycle awareness: Updates secrets on rollout for deployments, statefulsets, etc.
• 📄 Declarative configuration using CRDs like VaultStaticSecret, VaultDynamicSecret, and VaultPKISecret.

Just write YAML, apply it, and the operator does the rest.

Inside the Cluster: Namespaces and Syncing

The VSO runs in its own namespace (usually something like vault-secrets-operator), which helps keep things secure and easy to manage.

But it watches for CRDs in other namespaces, so it can sync secrets into the same namespace where your apps run.

Here’s what happens:

No Vault auth needed in the app. No sidecars. Just Kubernetes-native secret delivery.

What Kind of Secrets Can You Sync?

Short answer? All of them.

• ✅ Static secrets from KV stores
• ✅ Dynamic database or cloud credentials
• ✅ PKI certificates and more

And no matter what kind of secret it is, it ends up in a standard Kubernetes Secret—so your app just sees it like any other value.

Wrapping Up

That’s your intro to the Vault Secrets Operator.

It simplifies secret delivery, keeps apps secure and Vault-unaware, and fits right into Kubernetes-native workflows. And remember—it’s officially part of the Vault Associate exam, so understanding how it works will absolutely pay off.

Note: Make sure to check out my course here, where I include links and coupons to ensure all my content is accessible to everyone.