Skip to main content
πŸŽ“ Claude Code Masterclass Learn AI-assisted development on Udemy β€” plus the companion book on Leanpub & Amazon. Start Learning
Vault vs Sealed Secrets: Kubernetes Secrets
Platform Engineering

Vault vs Sealed Secrets 2026: Kubernetes Secrets Management

HashiCorp Vault vs Bitnami Sealed Secrets compared for 2026. Dynamic secrets, encryption, GitOps compatibility, and which secrets solution to use in Kubernetes.

LB
Luca Berton
Β· 2 min read

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/db

Sealed 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 cluster

Feature Comparison

CapabilityVaultSealed Secrets
Dynamic secretsYes (database, AWS, PKI)No (static only)
Secret rotationAutomatic (TTL-based)Manual (re-seal and apply)
Encryption at restYes (Shamir/auto-unseal)Yes (RSA asymmetric)
GitOps compatibleVia External Secrets OperatorNative (encrypted manifests in Git)
Audit loggingFull request audit trailKubernetes audit only
Access controlFine-grained policies per pathKubernetes RBAC on namespace
Multi-clusterCentralized for all clustersPer-cluster controller + keys
Setup complexityHigh (HA, unseal, backup)Low (single controller)
Operational costSignificant (dedicated infra)Minimal (one Deployment)
PKI / certificatesBuilt-in CA and cert issuanceNo
Transit encryptionYes (encrypt/decrypt API)No
Cloud provider credsDynamic AWS/GCP/Azure IAMNo

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 credentials

This 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: password

Decision 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.

Free 30-min AI & Cloud consultation

Book Now