SOPS vs Sealed Secrets vs External Secrets Operator: GitOps Secrets in 2026

Storing secrets in Git is a solved problem — but there are three very different solutions, and picking the wrong one costs you months of migration pain. Here is a direct comparison of SOPS, Sealed Secrets, and External Secrets Operator (ESO) so you can pick confidently.

The Core Problem

In a GitOps world, everything lives in Git. But a raw Kubernetes Secret is just base64 — anyone with repo access can decode it. You need secrets to be either encrypted in Git, or never in Git at all.

That gives you two approaches:

• Encrypt-in-git (SOPS, Sealed Secrets) — secrets live in the repo but are encrypted
• Reference-in-git (ESO) — secrets live in an external vault; Git only holds a reference

Option 1: SOPS (Mozilla)

SOPS encrypts files directly. You can encrypt a Kubernetes Secret YAML, a .env file, or any structured file. It supports AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault, and GPG.

Install:

brew install sops
# or download from https://github.com/getsops/sops/releases

Encrypt a secret:

# Using AWS KMS
export SOPS_KMS_ARN="arn:aws:kms:ap-south-1:123456789012:key/your-key-id"
 
sops --encrypt --kms $SOPS_KMS_ARN k8s-secret.yaml > k8s-secret.enc.yaml

Decrypt at deploy time (in CI):

sops --decrypt k8s-secret.enc.yaml | kubectl apply -f -

GitOps with ArgoCD (argocd-vault-plugin or helm-secrets):

helm plugin install https://github.com/jkroepke/helm-secrets
helm secrets upgrade myapp ./chart -f secrets.enc.yaml

Pros:

• Works with any file type, not just Kubernetes Secrets
• KMS key rotation is straightforward
• Audit trail via KMS CloudTrail
• Decryption happens outside the cluster — simpler architecture

Cons:

• Developers need AWS/GCP credentials to edit secrets locally
• Easy to accidentally commit unencrypted file
• ArgoCD integration requires a plugin (argocd-vault-plugin adds complexity)
• Key management is your responsibility

Option 2: Sealed Secrets (Bitnami/Helm)

Sealed Secrets runs a controller inside your cluster. You encrypt a secret using the cluster's public key. Only the controller (which holds the private key) can decrypt it. The encrypted SealedSecret CRD is safe to commit to Git.

Install:

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets -n kube-system
 
# Install kubeseal CLI
brew install kubeseal

Seal a secret:

kubectl create secret generic db-password \
  --from-literal=password=supersecret \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-password-sealed.yaml

Commit db-password-sealed.yaml to Git. ArgoCD applies it. Controller decrypts.

Pros:

• Zero external dependencies — works completely offline
• Natural fit for ArgoCD — apply the CRD, controller does the rest
• No credentials needed on developer machines to encrypt (public key is public)
• Namespace-scoped by default (extra safety)

Cons:

• Secrets are still in Git (just encrypted) — if the cluster private key leaks, all secrets are exposed
• Key rotation is painful — you must re-seal every secret
• No cross-cluster sharing — a secret sealed for cluster A cannot be used in cluster B
• Audit trail is limited

Option 3: External Secrets Operator (ESO)

ESO syncs secrets from an external store (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, 1Password) into Kubernetes Secrets. Nothing sensitive ever touches Git.

Install:

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace

Configure a SecretStore (AWS Secrets Manager example):

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secretsmanager
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-south-1
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: aws-credentials
            key: access-key-id
          secretAccessKeySecretRef:
            name: aws-credentials
            key: secret-access-key

Create an ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: SecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: production/database
        property: password

ESO creates a real Kubernetes Secret named db-credentials — your app uses it normally.

Pros:

• No secrets in Git at all — cleanest security posture
• Automatic rotation sync (refreshInterval)
• Works across clusters (same Vault/SM secret, multiple clusters)
• Full audit trail in the secret store (CloudTrail, Vault audit logs)
• Secret rotation happens without redeployment

Cons:

• External dependency — if AWS SM or Vault is down, new pods cannot pull secrets
• More moving parts to configure and debug
• IAM/RBAC setup is non-trivial
• Cost: AWS Secrets Manager charges $0.40/secret/month

Decision Table

Which One to Pick

Pick SOPS if: You have a small team, no Kubernetes cluster yet (e.g., ECS or plain VMs), or you need to encrypt non-Kubernetes files like .env or Ansible vault files. Also good if you are already using AWS KMS for other things.

Pick Sealed Secrets if: You want the simplest GitOps setup with no external dependencies. Good for teams that are new to Kubernetes and want "just commit it to Git and ArgoCD handles it." Single cluster deployments.

Pick ESO if: You are running multiple clusters, you need automatic secret rotation, or your organization already has HashiCorp Vault or AWS Secrets Manager. This is the enterprise-grade choice and what most mature platform teams end up on.

Most teams start with Sealed Secrets and graduate to ESO when they hit the multi-cluster or rotation wall.

Affiliate Tools

Managing secrets at scale? HashiCorp Vault on HCP pairs perfectly with ESO. For a full GitOps platform, Argo CD works natively with all three approaches.