HashiCorp Vault is a full secrets management platform with dynamic secrets, encryption as a service, and identity-based access. Bitnami Sealed Secrets encrypts Kubernetes Secrets so they can be safely stored in Git. They solve different problems at different scales.
Architecture
Vault runs as a server (or cluster) with a storage backend. Applications authenticate via Kubernetes Service Account, AppRole, or other methods, then request secrets at runtime. Vault can generate short-lived credentials on demand.
# Vault Agent Injector β sidecar pattern
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
template:
metadata:
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/role: "api-server"
vault.hashicorp.com/agent-inject-secret-db: "database/creds/api"
spec:
serviceAccountName: api-server
containers:
- name: app
image: myapp:latest
# Secret appears at /vault/secrets/dbSealed Secrets has two components: a cluster-side controller and a CLI tool (kubeseal). You encrypt a regular Secret into a SealedSecret CRD. Only the controller (with its private key) can decrypt it. The encrypted manifest is safe to commit to Git.
# Create a regular Secret, then seal it
kubectl create secret generic db-creds \
--from-literal=username=admin \
--from-literal=password=s3cret \
--dry-run=client -o yaml | \
kubeseal --format yaml > sealed-db-creds.yaml
# sealed-db-creds.yaml is safe to commit to Git
kubectl apply -f sealed-db-creds.yaml
# Controller decrypts β creates regular Secret in clusterFeature Comparison
| Capability | Vault | Sealed Secrets |
|---|---|---|
| Dynamic secrets | Yes (database, AWS, PKI) | No (static only) |
| Secret rotation | Automatic (TTL-based) | Manual (re-seal and apply) |
| Encryption at rest | Yes (Shamir/auto-unseal) | Yes (RSA asymmetric) |
| GitOps compatible | Via External Secrets Operator | Native (encrypted manifests in Git) |
| Audit logging | Full request audit trail | Kubernetes audit only |
| Access control | Fine-grained policies per path | Kubernetes RBAC on namespace |
| Multi-cluster | Centralized for all clusters | Per-cluster controller + keys |
| Setup complexity | High (HA, unseal, backup) | Low (single controller) |
| Operational cost | Significant (dedicated infra) | Minimal (one Deployment) |
| PKI / certificates | Built-in CA and cert issuance | No |
| Transit encryption | Yes (encrypt/decrypt API) | No |
| Cloud provider creds | Dynamic AWS/GCP/Azure IAM | No |
Dynamic Secrets: Vaultβs Killer Feature
Vault does not just store secrets β it generates them on demand with automatic expiration:
# Vault creates a temporary database credential
vault read database/creds/api-readonly
# Returns:
# username: v-k8s-api-readonly-abc123
# password: A1b2C3d4E5-randomized
# lease_duration: 1h
# lease_id: database/creds/api-readonly/abc123
# After 1 hour, Vault automatically revokes the credential
# The database user is deleted β no stale credentialsThis eliminates long-lived credentials entirely. If an attacker exfiltrates a credential, it expires within minutes or hours rather than lasting forever.
Sealed Secrets stores static values. Rotation means creating a new Secret, sealing it, committing, and redeploying. There is no automatic expiration.
GitOps Integration
Sealed Secrets was designed for GitOps. The encrypted SealedSecret YAML goes into your Git repository alongside your deployments. ArgoCD or Flux applies it, and the controller decrypts it in-cluster.
Vault requires an intermediary. The most common pattern is External Secrets Operator (ESO), which syncs Vault secrets into Kubernetes Secrets:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-creds
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: username
remoteRef:
key: secret/data/production/db
property: username
- secretKey: password
remoteRef:
key: secret/data/production/db
property: passwordDecision Guide
Use Sealed Secrets when:
- You need GitOps-native secrets storage
- Your secrets are static (API keys, passwords that rotate infrequently)
- You want minimal operational overhead
- Your team is small and a single cluster is sufficient
- You are starting your Kubernetes secrets journey
Use Vault when:
- You need dynamic, short-lived credentials (database, cloud IAM)
- You manage secrets across multiple clusters and platforms
- Compliance requires full audit trails of secret access
- You need PKI certificate management
- You want encryption as a service (Transit engine)
Use both together: Many organizations use Vault as the source of truth and External Secrets Operator to sync into Kubernetes, while still using Sealed Secrets for simple static values in GitOps pipelines.