Manage Secrets in GitOps with Sealed Secrets

By Khimananda Oli | Last reviewed: August 2026

The fundamental promise of GitOps is that your Git repository serves as the single source of truth for your entire infrastructure state. This model breaks immediately when you need to store database passwords, API keys, or TLS certificates because committing plaintext credentials to version control is a critical security failure. To manage secrets in GitOps with Sealed Secrets, you encrypt sensitive data locally using a public key so it can be safely committed to Git, while only the in-cluster controller holds the private key needed to decrypt it into usable Kubernetes Secrets.

This approach preserves the declarative workflow without resorting to manual post-deployment steps or external vault dependencies for every environment. For teams adopting GitOps with ArgoCD, this pattern eliminates the drift between what is declared in Git and what actually runs in the cluster. If you are new to the broader ecosystem of credential handling, start with my guide on Kubernetes secrets management done right before implementing encryption layers.

How do you install and configure Sealed Secrets for GitOps?

Before you can encrypt anything, the Sealed Secrets controller must be running in your target cluster. This component generates the key pair on first boot and exposes the public certificate via an HTTP endpoint. In production environments, especially those requiring SOC 2 or ISO 27001 compliance, you should never rely on the auto-generated keys. Instead, supply your own pre-generated RSA key pair stored securely in a backup system or hardware security module.

Installing the Controller via Helm

Helm is the standard deployment method in 2026. Add the Bitnami chart repository and install the controller into a dedicated namespace:

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm repo update

helm install sealed-secrets-controller sealed-secrets/sealed-secrets \
  --namespace kube-system \
  --set resources.requests.cpu=100m \
  --set resources.requests.memory=128Mi \
  --set resources.limits.memory=256Mi

Verify the pod is running and fetch the public certificate that developers will use for encryption:

kubectl get pods -n kube-system -l app.kubernetes.io/name=sealed-secrets
kubeseal --fetch-cert > sealed-secrets-cert.pem

Store this sealed-secrets-cert.pem file in your team’s shared configuration repository or distribute it via your internal developer platform. It is not sensitive — it is a public key — but losing it means developers cannot seal new secrets until they fetch a fresh copy.

Key Rotation and Backup Strategy

A common mistake in audits is finding no evidence of key rotation or backup procedures. The controller stores its private key as a Kubernetes Secret named sealed-secrets-key in the same namespace. You must back up this secret externally. If the cluster is destroyed and recreated without restoring this key, all existing SealedSecrets in Git become permanently undecryptable.

• Backup: Export the private key quarterly and store it in an offline, access-controlled vault.
• Rotation: The controller supports multiple active keys. Trigger rotation by sending SIGUSR1 to the pod or setting --key-renew-period. Old keys remain valid for decryption during the transition window.
• Disaster Recovery: Document the restore procedure in your runbooks. Test restoration annually as part of compliance evidence collection.

How do you encrypt and commit secrets safely with kubeseal?

The kubeseal binary performs client-side encryption. It contacts the controller (or uses a cached certificate) to obtain the public key, then encrypts each value in your Secret manifest individually. The output is a SealedSecret custom resource that is safe to store anywhere.

Basic Encryption Workflow

Create a standard Kubernetes Secret manifest locally. Do not commit this file:

# secret.yaml — DO NOT COMMIT
apiVersion: v1
kind: Secret
metadata:
  name: app-db-credentials
  namespace: production
type: Opaque
stringData:
  DB_HOST: postgres.prod.internal
  DB_USER: app_service
  DB_PASS: SuperS3cret!2026

Seal it using the fetched certificate:

kubeseal --cert sealed-secrets-cert.pem \
  --format yaml \
  < secret.yaml \
  > sealed-secret.yaml

The resulting sealed-secret.yaml contains encrypted blobs under spec.encryptedData. This file is now safe to commit to Git. Delete the original plaintext secret.yaml immediately after sealing.

Namespace and Name Binding

By default, Sealed Secrets are bound to the exact namespace and name specified in the metadata. Renaming the resource or moving it to a different namespace after sealing will cause decryption to fail silently. This is a deliberate security feature preventing lateral movement if an attacker gains write access to Git. If you require reusability across namespaces, use the --scope namespace-wide or --scope cluster-wide flags during sealing, but understand this weakens the security boundary significantly.

How does Sealed Secrets compare to External Secrets Operator and SOPS?

Choosing the right tool depends on your team’s operational maturity, compliance requirements, and existing cloud investments. There is no universal best option — only trade-offs. Understanding these differences prevents costly migrations later when you realize your chosen solution doesn’t fit your audit scope or multi-cloud strategy.

For Nepali startups and SMEs operating on tight budgets without enterprise cloud agreements, Sealed Secrets removes the recurring cost of managed secret stores while maintaining acceptable security posture. Enterprises pursuing SOC 2 Type II or ISO 27001 certification often prefer ESO because cloud provider audit logs satisfy evidence requirements more easily than self-managed key rotation records. Teams already standardized on HashiCorp Vault for secrets management should use ESO as the bridge rather than adopting Sealed Secrets as a parallel system.

What are the common pitfalls when managing secrets in GitOps with Sealed Secrets?

After reviewing dozens of GitOps implementations across Nepal and global clients, I see the same failures repeatedly. These aren’t theoretical risks — they cause production outages and audit findings.

Silent Decryption Failures

The controller does not crash when it cannot decrypt a SealedSecret. It logs an error and updates the resource status, but ArgoCD may still report the sync as successful because the SealedSecret CR itself was applied correctly. Always check the status.conditions field on SealedSecret resources in your monitoring dashboards. Set up alerts for Synced=False conditions using Prometheus metrics exported by the controller.

Certificate Drift Between Environments

Each cluster has its own key pair. Using a staging cluster’s certificate to seal secrets intended for production will result in decryption failures. Label your certificates clearly (prod-cert.pem, staging-cert.pem) and enforce validation in CI pipelines before merging. A simple pre-commit hook verifying the certificate fingerprint against the target environment prevents this class of errors entirely.

Overlooking RBAC Restrictions

The controller needs permissions to read SealedSecrets and create/update native Secrets in every namespace where you deploy applications. Missing ClusterRole bindings cause silent failures. Verify RBAC during installation and restrict the controller’s ServiceAccount to only the namespaces it actually manages — never grant cluster-admin privileges for convenience.

Storing Plaintext Temporarily

Developers often create plaintext Secret files, seal them, then forget to delete the originals. Add *.secret.yaml and similar patterns to .gitignore globally. Better yet, pipe directly from stdin to avoid intermediate files:

kubectl create secret generic app-db-credentials \
  --from-literal=DB_HOST=postgres.prod.internal \
  --from-literal=DB_USER=app_service \
  --from-literal=DB_PASS=SuperS3cret!2026 \
  --dry-run=client -o yaml | \
  kubeseal --cert prod-cert.pem --format yaml > sealed-secret.yaml

This one-liner never writes plaintext to disk. Integrate it into your team’s documentation and onboarding materials for handling secrets in CI/CD pipelines safely.

Implementing Secure Secret Management in Your GitOps Pipeline

To successfully manage secrets in GitOps with Sealed Secrets, treat the encryption workflow as a first-class part of your delivery pipeline, not an afterthought. Automate certificate distribution through your internal developer platform or config repo. Enforce pre-commit hooks that reject plaintext Secret manifests. Monitor decryption status alongside application health metrics. Rotate keys on a documented schedule and test restoration procedures before auditors ask.

This pattern gives you true GitOps — declarative, versioned, auditable — without sacrificing security or compliance readiness. For teams in Nepal building cloud-native products on limited budgets, it removes the barrier of expensive managed secret stores while maintaining professional-grade security practices. Global teams use it as a lightweight complement to enterprise vaults for non-critical environments or edge deployments.

If your team needs help designing a secrets management strategy that passes audits and survives production incidents, reach out to discuss your specific architecture. I’ve implemented this pattern across regulated fintech systems, government platforms, and high-growth startups — the right solution depends on your compliance scope, team size, and cloud footprint.