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.
Planning the move from sealed manifests to an external secrets manager
The migration is less about swapping one secret format for another and more about changing how Kubernetes workloads obtain credentials. Treat Sealed Secrets as an encrypted delivery mechanism and the external secrets manager as the source of truth. That means you must decide where secrets will live, how clusters will authenticate, and how teams will preserve GitOps drift control during the transition.
Start with a secret inventory that distinguishes application secrets, cluster-specific values, and credentials that should never be stored in Git again. The target design then becomes a contract between Git, the cluster controller, and the external store: Git declares desired references, while the runtime controller resolves them at sync time. In practice, that usually means replacing encrypted manifests with external references and provisioning a dedicated workload identity or service account for cluster access.
For GitOps teams, the key design choice is whether you want one external store per environment, a shared store with tenancy boundaries, or a hybrid model. The integration path should follow your existing deployment pattern, because the operational cost usually sits in access control, naming conventions, and review workflow rather than in the secret objects themselves. The GitOps Security Guide is the best starting point when you need to keep repository workflow, tenancy, and drift management aligned during the migration.
How to preserve control while Git stops carrying the secret payload
Once the platform is in place, the main engineering task is to make the cluster authentication path explicit and minimal. That includes choosing a machine identity or service account with only the permissions needed to read the required secret paths, then validating that the external secrets controller can sync, refresh, and fail safely. The move is successful only when Git becomes declarative metadata, not a transport for sensitive values.
This is where teams often underestimate the blast radius of “temporary” access. If the controller can read too broadly, one namespace or environment can start depending on another, and the migration quietly reintroduces the cross-environment coupling that GitOps is meant to reduce. The External Secrets Operator security guide is useful for hardening tenant boundaries, controller permissions, and sync policy before you scale rollout.
Review the secret lifecycle as part of the migration, not after it. Credentials that were safe enough to encrypt and commit can become overexposed once they are moved into a central service, especially if teams keep long-lived values or reuse the same material across clusters. For a broader view of this shift from stored secrets to runtime retrieval, see the Secrets Management Guide, which covers secret zero, rotation, and moving toward secretless access patterns.
What to validate before broad cutover
A migration like this needs a staged verification plan, because the failure modes are operational as much as technical. Prove that the new path works in a non production cluster first, then confirm that the application still starts, refreshes secrets on schedule, and fails closed when the external store is unavailable. Keep rollback manifests in Git until you have evidence that the new flow is stable under redeploy, restart, and rotation events.
Validation should also cover auditability and response. You need to know who requested a secret, which controller or workload identity performed the lookup, and whether the access trail is good enough for incident review. If the secret backend exposes access logs, wire them into your monitoring before you retire the old manifests. The Secrets Access Logging and Detection guide is a practical reference for the audit signals that matter during cutover and steady state.
For Kubernetes-specific control points, the external store should be paired with namespace scoping, RBAC review, and a clear policy on whether workloads may create, refresh, or merely consume secret references. The Kubernetes Secrets Security Guide remains relevant because the cluster side still needs encryption, access control, and audit discipline even after the payload leaves Git.
Risk and Threat Considerations
The main risk in this migration is that teams remove secret payloads from Git but leave the access model too loose. If the external manager is broadly readable, a compromise of the controller, service account, or workload identity can expose more secrets than the original sealed manifests ever did. The danger is not just disclosure, it is uncontrolled propagation across namespaces, clusters, or environments.
Failure mechanism: Excessive read scope, weak tenant separation, or reused identities let one compromised workload retrieve secrets beyond its intended blast radius, and a broken sync policy can silently keep delivering stale or overprivileged values.
Impact: Attackers or insiders can pivot from a single namespace into wider application access, and operators can lose confidence in rollback, rotation, and audit evidence when the new secret path is not tightly bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Cluster-to-vault authentication is central to external secret retrieval. |
| AC-6 — Least Privilege | The migration depends on tightly scoping what each workload can read. | |
| AU-2 — Event Logging | Audit logging is needed to verify secret access and cutover behaviour. | |
| Recommendation — Use IA-9 to bound workload authentication to the secret backend. Apply AC-6 to limit secret-read access to the minimum required paths. Enable AU-2 logging for secret access and controller activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A cluster workload or controller can become overprivileged during the migration. |
| NHI-07 — Long-Lived Secrets | The move away from sealed manifests should also reduce long-lived credential use. | |
| Recommendation — Reduce controller and workload permissions to the minimum needed. Replace long-lived secret handling with short-lived retrieval or rotation. | ||
Practitioner Guidance
What to prioritise: Treat identity and scope as the first cutover gate, not the last. If the external store and controller permissions are not sharply bounded, do not migrate more applications simply because sync works.
What to verify: Confirm that each workload can read only the paths it needs, that refresh behaviour is observable, and that revocation or rotation in the backend actually changes what the cluster receives.
Decision rule: If the application can tolerate a brief secret refresh delay, prefer a slower, more observable rollout with rollback manifests and explicit approval checkpoints. If it cannot, isolate it into a separate migration wave.
Practitioner takeaway: The safest migration is the one where Git loses secret material, but the runtime access path becomes more controlled, not merely more convenient.
Related resources from NHI Mgmt Group
- What is the difference between keeping secrets in Sealed Secrets and using an external secrets manager with GitOps?
- What is the difference between Kubernetes-native secrets and secrets that can be moved to an external secrets manager?
- Why does moving secrets to an external manager improve security in Kubernetes?
- When does secrets rotation actually reduce NHI risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org