TL;DR: Many Kubernetes backup tools protect only persistent volumes or VM substrates, while complete recovery also needs namespace configuration, manifests, Secrets, CRDs and etcd state so workloads can be restored across clusters or clouds, according to HYCU. That gap makes workload-aware backup, not storage snapshots alone, the real requirement for Kubernetes resilience.
At a glance
What this is: This is an analysis of Kubernetes backup that concludes full recovery requires application state, configuration, and control plane data, not just node or volume backups.
Why it matters: For IAM and cloud security teams, it shows that Kubernetes resilience depends on protecting the configuration and identity-adjacent state that makes workloads runnable, portable, and recoverable.
Context
Kubernetes backup fails when teams treat the platform like a collection of virtual machines instead of a distributed application system. A backup that captures only the underlying nodes or even only persistent storage can leave the workload unrecoverable because the namespace, manifests, Secrets, and cluster state are what define how the application actually runs.
The identity and access angle is real here because Kubernetes workloads rely on service accounts, Secrets, RBAC bindings, and other Kubernetes NHI security controls to restore both function and access safely. That makes backup part of broader workload governance, not just storage hygiene.
Key questions
Q: What should teams do first when Kubernetes backup only covers persistent volumes?
A: Start by inventorying the objects that make the workload runnable, not just the data files. That means checking whether namespace configuration, manifests, Secrets, CRDs, and control plane state are included in the recovery scope. If they are missing, the team has storage protection, not workload protection.
Q: Why does Kubernetes recovery fail even when the data is backed up?
A: Because data alone does not recreate the application. Kubernetes workloads depend on object relationships, configuration, and cluster state, so a restored volume without manifests, Services, and related control plane objects can be unusable. Recovery fails when teams confuse preserved bytes with a runnable system.
Q: How can security teams know whether Kubernetes backup is actually working?
A: A good test is whether the team can restore the workload to a different cluster or cloud and still recover the application, its access bindings, and its dependencies without manual reconstruction. If the restore requires improvised fixes, the backup process is incomplete.
Q: Should organisations back up Kubernetes control plane state as well as application data?
A: Yes, unless the environment is fully reproducible from source control and GitOps discipline is already mature. etcd, RBAC, CRDs, and admission rules often contain the operational truth needed to rebuild the cluster. If those elements are not reproducible, they belong in the backup strategy.
Technical breakdown
Why persistent volumes are not enough for Kubernetes recovery
Persistent volumes protect application data, but Kubernetes recovery depends on more than data files. The cluster also needs namespace-scoped objects such as Deployments, StatefulSets, Services, ConfigMaps, Secrets, Ingress rules, and Custom Resource Definitions. Those objects define runtime behaviour, dependencies, and access patterns. If they are missing, restored storage may contain the state but not the application context needed to use it. In practice, Kubernetes backup has to capture object relationships, not just byte-level contents, because the workload is assembled from multiple API objects rather than a single host image. See the Cloud Workload Identity Guide.
Practical implication: Treat persistent volume snapshots as one layer of protection, not the backup strategy itself.
How control plane state changes the restore problem
Kubernetes is governed by etcd, which stores the cluster's source of truth for what should exist. That includes workload definitions, RBAC rules, CRDs, and admission webhooks. If etcd is not captured or reproducible from source control, restore becomes a reconstruction exercise rather than a recovery exercise. The challenge is not only preserving data, but preserving the object model that tells the cluster how to interpret that data. This is why backup design must account for both application state and control plane state, especially in environments that are not GitOps-pure.
Practical implication: Verify whether your recovery plan can rebuild cluster state, not just restore application files.
Why labels and metadata matter to backup automation
Kubernetes labels and metadata let workloads declare what they are, when they changed, and how related resources should be grouped. That makes them a control surface for backup policy. A backup platform can watch the API, discover workloads dynamically, and bind protection rules based on labels instead of manual inventory. This is the core architectural difference from legacy backup approaches that depend on static registration. In Kubernetes, protection has to follow the workload lifecycle, because the workload itself may be ephemeral even when the service is business-critical. Read Guide to SPIFFE and SPIRE.
Practical implication: Use metadata-driven discovery so backup policies track workloads automatically as they move or scale.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Complete Kubernetes backup is a governance problem, not a storage problem. The article's core point is that backup strategies fail when they assume the container substrate is the workload. That is the wrong unit of recovery, because Kubernetes distributes application identity across objects, policies, and cluster state. Practitioners should treat recovery design as workload governance, not infrastructure archiving.
The named failure mode here is substrate-only recovery. When teams back up nodes or volumes but omit manifests, Secrets, and etcd, they preserve data without the instructions required to run it. Kubernetes NHI security matters because access bindings and service-level identity are part of what makes the restored workload usable. Practitioners should test whether backup captures the runnable system, not just the storage layer.
Control plane state is the difference between restoration and archaeology. etcd, RBAC, CRDs, and admission controls are not optional metadata in mature Kubernetes environments. They are the operational memory of the cluster. Where GitOps is incomplete or manual changes accumulate, the backup surface expands beyond application objects into governance state. Practitioners should define which control plane elements are source-controlled and which must be backed up.
Kubernetes-native protection should follow the workload, not the administrator's spreadsheet. The article correctly frames labels and metadata as the mechanism for dynamic discovery and policy binding. That aligns with how cloud-native systems actually behave, where pods move, namespaces proliferate, and protection needs change faster than manual inventory can keep up. Practitioners should design for policy-driven discovery and restore orchestration, not static backup lists.
Cross-cluster restore is now the real test of backup maturity. The practical benchmark is no longer whether a team can snapshot a cluster, but whether it can recover workload identity, configuration, and dependencies into a different region or cloud with minimal manual repair. That is where incomplete Kubernetes backup strategies break down. Practitioners should validate portability as part of every disaster recovery exercise.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
- Read next: Kubernetes NHI Security Guide
What this signals
Substrate-only recovery: Kubernetes teams still overestimate what a volume snapshot can restore. The harder part is not preserving bytes, but preserving the object relationships and control plane state that make a workload operational after failure. That shifts backup from a storage exercise to a governance and recovery-design exercise.
Kubernetes resilience now depends on whether recovery can follow the workload across clusters and clouds without manual repair. Teams that cannot restore namespaces, manifests, and access bindings together will keep discovering that successful backup jobs do not guarantee successful recovery.
For practitioners
- Define backup scope at the workload level Map each critical Kubernetes application to the namespace, manifests, ConfigMaps, Secrets, CRDs, and persistent volumes that must be restored together.
- Test recovery beyond the original cluster Run restore exercises into a different cluster and region, and confirm the application comes back with its dependencies and access bindings intact.
- Separate storage snapshots from full workload backup Use CSI or volume snapshots as one input, but require a process that also captures cluster objects and control plane state.
- Automate discovery with labels and metadata Bind protection policies to workload labels so new applications are discovered and covered without manual registration.
Key takeaways
- Kubernetes backup breaks down when teams protect only the substrate and not the workload definition that makes the application runnable.
- The article shows that full recovery depends on persistent volumes, namespace objects, Secrets, and control plane state working together.
- Practitioners should test restore into a different cluster or cloud to prove that the backup can reconstruct the application, not just its data.
Related NHI Mgmt Group resources: Kubernetes NHI Security Guide · Cloud Workload Identity Guide · Guide to SPIFFE and SPIRE · Cloud Security Guide
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Kubernetes backup must preserve and protect Secrets as part of workload recovery. |
| NHI-08 — Environment Isolation | Cross-cluster restore and multi-cloud recovery depend on preserving environment boundaries and configuration. | |
| Recommendation — Include Secrets in backup scope and ensure exposed or stale secrets are revoked during restore testing. Validate that restored workloads preserve isolation assumptions across clusters, regions, and cloud environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Kubernetes restore depends on RBAC and access bindings being recoverable with the workload. |
| Recommendation — Recover and verify access permissions alongside application state so restored clusters remain authorised correctly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service identities and access bindings are part of Kubernetes operational recovery scope. |
| Recommendation — Track and restore workload-related accounts and bindings as part of your backup and recovery process. | ||
| MITRE ATT&CK | TA0007 — Discovery | The article emphasises auto-discovery and workload identification as core to backup coverage. |
| Recommendation — Use discovery to identify every workload and protect it before manual inventory gaps appear. | ||
Key terms
- Kubernetes Backup: Kubernetes backup is the process of preserving the data, configurations, and resources that make a cluster recoverable. Effective backup must cover more than running containers, including persistent storage and cluster metadata. It is a core resilience control for restoring applications after ransomware, deletion, corruption, or failed migration.
- Etcd: Etcd is the distributed key-value store used by Kubernetes as part of its control plane. When Secrets are persisted there without encryption at rest, anyone with sufficiently broad control-plane or backend access may recover the underlying values, which makes etcd a critical governance boundary.
- Control-Plane State: Control-plane state is the metadata a service uses to decide what devices, users, or systems are allowed to do. When that state is corrupted or unavailable, the effect can look like an access or authorisation failure even if authentication itself is intact.
- Workload-Level Recovery: Workload-level recovery restores the full application unit rather than a single pod or volume. In Kubernetes, that means bringing back the namespace, configuration, data, and related objects together so the service behaves as intended after failover or migration.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the cloud and Kubernetes systems they have to recover and govern.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org