Describe the solution you'd like
Define and document the supported ownership-conflict and orphan-recovery behavior for Gatekeeper-generated ValidatingAdmissionPolicies (VAPs) and ValidatingAdmissionPolicyBindings (VAPBindings). Cover template-owned policies, constraint-owned bindings, and the per-constraint policy topology being developed in connection with #4530.
Once an owner reference is removed, a deterministic resource name does not distinguish a Gatekeeper orphan from an independently created resource. Retaining an object with ambiguous ownership is intentional safety behavior; this issue is not a request to delete all ownerless objects.
Scenarios to address:
- The owner reference is removed while Gatekeeper is running or while it is stopped.
- The parent constraint/template is deleted before ownership can be repaired.
- A generated resource is deleted and another object is created with the same name but a different UID.
- A parent is recreated with the same name but a different UID.
- The resource has a conflicting controller owner.
Acceptance criteria:
- Never adopt, modify, or delete an existing resource solely because its name or managed-by label matches Gatekeeper's naming convention. Do not override another controller's ownership.
- Define which situations require operator intervention, surface actionable ownership conflicts, and document a manual recovery procedure that makes the effect on existing admission enforcement explicit.
- Decide whether automatic recovery is needed before selecting a persistence design. If supported, require trusted evidence identifying the exact parent and generated-resource UIDs, verify the current live object, and use appropriate UID/resourceVersion preconditions to avoid acting on replacements or concurrent ownership changes.
- If durable bookkeeping is introduced, define how it survives restarts and parent deletion, handles a crash between resource creation and recording its UID, and is cleaned up safely. Existing ambiguous resources must not be silently enrolled by name.
- Add regression coverage for metadata removal, restarts, parent deletion/recreation, foreign same-name resources, and same-name child replacement across the relevant VAP/VAPBinding paths.
Anything else you would like to add:
Related to #4530. This is a separate lifecycle/design follow-up to ownership checks that reject adoption of an unowned existing VAP. An update event can identify the parent from the old owner reference, but the ordinary reconcile request does not preserve proof of the generated object's UID. That event alone is not a durable recovery mechanism.
Owner references and labels are writable metadata, not authentication credentials. This proposal does not claim to prevent hostile writers with permission to modify admission policies, and does not prescribe a persistent ownership registry before the recovery contract is agreed.
Environment:
Describe the solution you'd like
Define and document the supported ownership-conflict and orphan-recovery behavior for Gatekeeper-generated ValidatingAdmissionPolicies (VAPs) and ValidatingAdmissionPolicyBindings (VAPBindings). Cover template-owned policies, constraint-owned bindings, and the per-constraint policy topology being developed in connection with #4530.
Once an owner reference is removed, a deterministic resource name does not distinguish a Gatekeeper orphan from an independently created resource. Retaining an object with ambiguous ownership is intentional safety behavior; this issue is not a request to delete all ownerless objects.
Scenarios to address:
Acceptance criteria:
Anything else you would like to add:
Related to #4530. This is a separate lifecycle/design follow-up to ownership checks that reject adoption of an unowned existing VAP. An update event can identify the parent from the old owner reference, but the ordinary reconcile request does not preserve proof of the generated object's UID. That event alone is not a durable recovery mechanism.
Owner references and labels are writable metadata, not authentication credentials. This proposal does not claim to prevent hostile writers with permission to modify admission policies, and does not prescribe a persistent ownership registry before the recovery contract is agreed.
Environment: