Skip to content

Commit 57f7f50

Browse files
myasnikovdaniilmyasnikovdaniil
committed
docs(platform): clarify sequential self-protection on no-delete VAP
Address review feedback from @lexfrei on packages/core/platform/templates/ deletion-protection.yaml: both the ValidatingAdmissionPolicy and the ValidatingAdmissionPolicyBinding carry the no-delete label so each individually requires the bypass dance, but the labeling is symmetric, not truly bilateral. Removing the label from the Binding and deleting it first leaves the VAP labeled but unenforced, so the VAP itself is then deletable without the bypass — and vice versa. That is by design: the guardrail is operational guidance, not adversarial defense against an operator with cluster-admin who is determined to remove it. Add a paragraph in the template comment header so a future reader does not waste time wondering why the symmetric self-protection isn't truly bilateral. Forward-references the whole-chart teardown recipe (make unprotect) so the comment links to the documented escape hatch. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
1 parent 6782761 commit 57f7f50

1 file changed

Lines changed: 8 additions & 0 deletions

File tree

‎packages/core/platform/templates/deletion-protection.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,14 @@
1111
resources (omit it for cluster-scoped objects like CRDs and Namespaces).
1212
kubectl label <kind> <name> --namespace <ns> platform.cozystack.io/no-delete-
1313

14+
Self-protection is sequential, not bilateral: both the VAP and the Binding
15+
carry the no-delete label, but either one can be unlabeled and deleted
16+
first — once the Binding is gone, the VAP is unenforced and can be deleted
17+
without the dance, and vice versa. The labeling is operational guidance,
18+
not adversarial defense. Whole-chart teardown is via `make unprotect` (see
19+
packages/core/platform/Makefile), which strips the label from every
20+
guarded object so `helm uninstall` can proceed.
21+
1422
failurePolicy is intentionally omitted: the validation expression is the
1523
literal `false`, so CEL evaluation cannot fail and the default (Fail) is
1624
unreachable in practice. Setting it explicitly would be misleading config.

0 commit comments

Comments
 (0)