External Secrets vs Sealed Secrets: where SOPS and Vault fit

Applications need database passwords, API tokens and other credentials. You need a way to give each application the right values without putting readable secrets in a shared Git repository. You also need to replace those credentials and recover them if the cluster fails. Kubernetes Secrets hold values for applications, but base64 encoding in a Secret manifest does not encrypt them.

External Secrets copies values from an external secret store into Kubernetes. Sealed Secrets lets you commit encrypted Kubernetes secret manifests that a cluster controller can decrypt. SOPS encrypts selected values in configuration files so an authorized tool can decrypt them during deployment. Vault is a service for storing and issuing secrets, and can be the source used by another delivery tool. These products sometimes work together, so they are not four interchangeable replacements.

External Secrets vs Sealed Secrets: where do you manage the value?

Choose External Secrets when an external service already stores the credential and Kubernetes should receive a copy. Choose Sealed Secrets when you want an encrypted Kubernetes manifest in Git and can protect the cluster controller's decryption keys. The distinction is where updates begin: at the external secret store or in the encrypted manifest. SOPS offers another file-encryption workflow; Vault can provide the external secret service rather than replace every delivery tool.

• External Secrets: a controller retrieves values from an external source and reconciles Kubernetes Secrets. Review the controller's backend permissions and namespace boundaries.
• Sealed secrets: encrypted manifests are intended for a controller that can decrypt them. Protect and recover the relevant private keys.
• SOPS with GitOps: encrypted files live in Git and are decrypted by an authorized reconciliation path. Key access and Git history become part of the model.
• Vault: a secret service can provide storage and dynamic credentials; server operation, authentication and the delivery integration remain explicit responsibilities.

Test rotation all the way to the application

Changing the source value is only the first step. Confirm reconciliation, mounted-file or environment-variable behavior, application reload and revocation of the old credential. A restarted Pod might be necessary for some applications, but a blanket restart rule is not a substitute for knowing how the application reads secrets.

Recover the control path

Document how a new cluster obtains decryption authority or backend access without depending on a secret that only the failed cluster possessed. Test backups of keys and external services. Restrict controller permissions so one namespace cannot retrieve arbitrary secrets belonging to another team.

Failure and rollback

Decide what happens when the source is unavailable or a value is deleted. Do not assume existing Secrets disappear or refresh identically across tools. Keep old credentials valid only for a bounded overlap window, then revoke them deliberately. This page compares operating models; it does not claim a tested rotation fixture for every application.

Which approach fits?

Use External Secrets when an existing external store should remain the place where credentials are managed. Use Sealed Secrets when encrypted Kubernetes manifests in Git fit a small, clear deployment workflow and you can protect the controller keys. Use SOPS when you need encrypted values across configuration files and your deployment tooling supports decryption. Evaluate Vault when you need the secret service itself, especially its credential-issuing capabilities, and can operate or obtain that service. In every case, check that the application actually loads a rotated value.