{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "item": { "id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "slug": "review-kubernetes-reclaim-policy-before-deleting-a-storage-claim", "url": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim.md", "json": "https://update.dsesecurity.com/api/v1/posts/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/" }, "title": "Review Kubernetes reclaim policy before deleting a storage claim", "summary": "Deleting an application claim can have consequences outside the cluster’s API objects.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:14:49+00:00", "modified_at": "2026-10-20T18:34:31+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 265, "potentially_affected": "Review released PersistentVolumes and the supported storage asset affected by their reclaim policy.", "dse_recommendation": "DSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup.", "primary_source": { "name": "Kubernetes documentation — Persistent Volumes", "url": "https://kubernetes.io/docs/concepts/storage/persistent-volumes/", "published_on": null, "authority": "kubernetes.io" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Deleting an application claim can have consequences outside the cluster’s API objects.

\n

Source facts

\n

The reclaim policy on a Kubernetes PersistentVolume determines what happens after its claim is released. Retain leaves the volume and its previous data for manual reclamation; it is not immediately available for another claim. Delete can remove both the PersistentVolume and the associated supported storage asset. The selected policy therefore affects the post-deletion recovery path.

\n

Source: Kubernetes documentation — Persistent Volumes.

\n

Applicability

\n

Review released PersistentVolumes and the supported storage asset affected by their reclaim policy.

\n

DSE recommendation

\n

DSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup. Confirm which data must be preserved and where a usable recovery copy exists. Do not infer retention from the application’s deletion procedure or from an assumed StorageClass default. For retained assets, assign an owner and a controlled reclamation process so preserved data does not become untracked infrastructure. For deletion, require evidence that the business retention requirement has already been met elsewhere.

\n

Verification

\n

On a disposable volume, delete its test claim and inspect both Kubernetes objects and the backend asset. Confirm that the observed retention or deletion matches the recorded policy. Treat a successful backup job as insufficient until a suitable restore exercise has been completed. Keep the test backend identifier in the evidence so an absent API object cannot be mistaken for deleted storage. Have the data owner approve the retained-data handling or the separate recovery copy before repeating the procedure on a real retirement.

\n

Official reference

\n

Kubernetes documentation — Persistent Volumes. Reviewed October 20, 2026.

", "content_text": "Deleting an application claim can have consequences outside the cluster’s API objects.\nSource facts\nThe reclaim policy on a Kubernetes PersistentVolume determines what happens after its claim is released. Retain leaves the volume and its previous data for manual reclamation; it is not immediately available for another claim. Delete can remove both the PersistentVolume and the associated supported storage asset. The selected policy therefore affects the post-deletion recovery path.\nSource: Kubernetes documentation — Persistent Volumes.\nApplicability\nReview released PersistentVolumes and the supported storage asset affected by their reclaim policy.\nDSE recommendation\nDSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup. Confirm which data must be preserved and where a usable recovery copy exists. Do not infer retention from the application’s deletion procedure or from an assumed StorageClass default. For retained assets, assign an owner and a controlled reclamation process so preserved data does not become untracked infrastructure. For deletion, require evidence that the business retention requirement has already been met elsewhere.\nVerification\nOn a disposable volume, delete its test claim and inspect both Kubernetes objects and the backend asset. Confirm that the observed retention or deletion matches the recorded policy. Treat a successful backup job as insufficient until a suitable restore exercise has been completed. Keep the test backend identifier in the evidence so an absent API object cannot be mistaken for deleted storage. Have the data owner approve the retained-data handling or the separate recovery copy before repeating the procedure on a real retirement.\nOfficial reference\nKubernetes documentation — Persistent Volumes. Reviewed October 20, 2026.", "content_markdown": "Deleting an application claim can have consequences outside the cluster’s API objects.\n\n## Source facts\n\nThe reclaim policy on a Kubernetes PersistentVolume determines what happens after its claim is released. Retain leaves the volume and its previous data for manual reclamation; it is not immediately available for another claim. Delete can remove both the PersistentVolume and the associated supported storage asset. The selected policy therefore affects the post-deletion recovery path.\n\nSource: [Kubernetes documentation — Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).\n\n## Applicability\n\nReview released PersistentVolumes and the supported storage asset affected by their reclaim policy.\n\n## DSE recommendation\n\nDSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup. Confirm which data must be preserved and where a usable recovery copy exists. Do not infer retention from the application’s deletion procedure or from an assumed StorageClass default. For retained assets, assign an owner and a controlled reclamation process so preserved data does not become untracked infrastructure. For deletion, require evidence that the business retention requirement has already been met elsewhere.\n\n## Verification\n\nOn a disposable volume, delete its test claim and inspect both Kubernetes objects and the backend asset. Confirm that the observed retention or deletion matches the recorded policy. Treat a successful backup job as insufficient until a suitable restore exercise has been completed. Keep the test backend identifier in the evidence so an absent API object cannot be mistaken for deleted storage. Have the data owner approve the retained-data handling or the separate recovery copy before repeating the procedure on a real retirement.\n\n## Official reference\n\n[Kubernetes documentation — Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "url": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Review Kubernetes reclaim policy before deleting a storage claim", "item": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/#article", "identifier": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "url": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/", "headline": "Review Kubernetes reclaim policy before deleting a storage claim", "description": "Deleting an application claim can have consequences outside the cluster’s API objects.", "abstract": "Deleting an application claim can have consequences outside the cluster’s API objects.", "articleBody": "Deleting an application claim can have consequences outside the cluster’s API objects.\nSource facts\nThe reclaim policy on a Kubernetes PersistentVolume determines what happens after its claim is released. Retain leaves the volume and its previous data for manual reclamation; it is not immediately available for another claim. Delete can remove both the PersistentVolume and the associated supported storage asset. The selected policy therefore affects the post-deletion recovery path.\nSource: Kubernetes documentation — Persistent Volumes.\nApplicability\nReview released PersistentVolumes and the supported storage asset affected by their reclaim policy.\nDSE recommendation\nDSE recommends recording the actual volume, claim, storage backend identifier, and reclaim policy before any application retirement or namespace cleanup. Confirm which data must be preserved and where a usable recovery copy exists. Do not infer retention from the application’s deletion procedure or from an assumed StorageClass default. For retained assets, assign an owner and a controlled reclamation process so preserved data does not become untracked infrastructure. For deletion, require evidence that the business retention requirement has already been met elsewhere.\nVerification\nOn a disposable volume, delete its test claim and inspect both Kubernetes objects and the backend asset. Confirm that the observed retention or deletion matches the recorded policy. Treat a successful backup job as insufficient until a suitable restore exercise has been completed. Keep the test backend identifier in the evidence so an absent API object cannot be mistaken for deleted storage. Have the data owner approve the retained-data handling or the separate recovery copy before repeating the procedure on a real retirement.\nOfficial reference\nKubernetes documentation — Persistent Volumes. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:14:49+00:00", "dateModified": "2026-10-20T18:34:31+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-reclaim-policy-before-deleting-a-storage-claim/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review Kubernetes reclaim policy before deleting a storage claim" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 265, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes documentation — Persistent Volumes", "url": "https://kubernetes.io/docs/concepts/storage/persistent-volumes/" } } ] } }