How should teams migrate from Sealed Secrets to an external secrets manager in Kubernetes GitOps workflows?

Start by inventorying secrets, defining target environments, and choosing the integration path that matches your operating model. Deploy the external secrets platform, create a machine identity or service account for cluster authentication, and replace encrypted manifests with references in Git. Test in a non production cluster first, keep rollback manifests, and validate sync, access controls, and audit logging before broad cutover.

Why This Matters for Security Teams

Migrating from Sealed Secrets to an external secrets manager changes the control point for credentials, so the question is not just how to re-encrypt manifests. It is how to move from secrets stored and decrypted inside GitOps flows to runtime retrieval with tighter access control, auditability, and rotation. That shift reduces long-lived ciphertext in Git, but it also adds dependency on cluster identity, external availability, and policy correctness.

Teams usually make this move because static encryption has reached its limit. Sealed Secrets protects values at rest in Git, but it does not eliminate secret distribution, and it can still leave teams with duplicated keys, inconsistent rotation, and weak separation between environments. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly fragmented secret handling becomes operational debt. The NIST Cybersecurity Framework 2.0 is useful here because it frames the move as governance, not only tooling.

One useful benchmark: GitGuardian and CyberArk report that the average estimated time to remediate a leaked secret is 27 days, even though most organisations believe they are handling secrets well. In practice, many security teams discover the real problem only after a GitOps repo, cluster workload, or CI pipeline has already exposed a credential.

How It Works in Practice

The cleanest migration path is to treat the external manager as the source of truth and use Git only for references, not secret material. In a GitOps workflow, the controller still reconciles desired state from Git, but the workload retrieves the secret value from a vault, cloud secret store, or secrets service at runtime through a cluster identity. That identity should be explicit, short-lived where possible, and scoped to a namespace, service account, or workload role.

Start by mapping each sealed secret to one of three outcomes: move as-is to a managed secret, replace with a dynamic credential, or retire entirely. Then define the trust path between Kubernetes and the secrets manager. Common patterns include service-account-based authentication, OIDC federation, or workload identity. The key control is not the format of the secret in Git, but whether the pod can prove who it is before access is granted.

Operationally, teams should validate:

• Which controller will sync or render the external secret reference
• How the cluster authenticates to the secrets manager
• Whether namespace boundaries and RBAC match the new access model
• How rotation, revocation, and sync failure are audited
• How rollback works if the external store is unavailable

The migration also changes failure handling. Sealed Secrets tends to fail at deploy time if ciphertext or keys are wrong; external managers can fail later, at fetch time, when a pod starts or refreshes. That makes availability, retry logic, and alerting part of the secret design. The OWASP Non-Human Identity Top 10 is relevant because it highlights machine identity and secret misuse as first-class risks, and NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets helps frame why ephemeral access is usually stronger than encrypted static blobs. These controls tend to break down when clusters span multiple cloud accounts and each environment uses a different auth path, because secret ownership and trust boundaries become hard to keep consistent.

Common Variations and Edge Cases

Tighter secret centralisation often increases operational overhead, so teams have to balance cleaner governance against rollout complexity and platform dependency. Best practice is evolving, and there is no universal standard for this yet, especially in hybrid GitOps estates.

Some teams keep Sealed Secrets for bootstrap or break-glass scenarios while moving application secrets to the external manager. That can be reasonable during phased adoption, but it should be temporary and documented. Others use the external manager only for production, leaving non-production in Git-based encryption. That reduces migration risk, but it can create environment drift if auth, rotation, and naming conventions differ too much.

Two edge cases matter most. First, workloads that need startup secrets before the controller is available may require init container logic, CSI-style mounts, or fallback manifests. Second, teams with many namespaces or clusters need a consistent identity model, otherwise each cluster becomes a custom integration. NHIMG’s Guide to the Secret Sprawl Challenge is useful for understanding why fragmentation reappears if migration is not standardised. The practical warning is simple: if the new model cannot survive controller restarts, secret rotation, and environment replication, it is not yet ready for full GitOps cutover.

Related resources from NHI Mgmt Group

• How should teams reduce the risk from exposed NHI secrets?
• How should security teams govern Kubernetes secrets when the sync bridge is maintained separately from the secrets manager?
• How should security teams manage external secrets synchronization for Kubernetes without creating secrets sprawl?
• What breaks when teams manually copy secrets between Kubernetes and external vaults?