Deep Review: 20260321-005431-pr-243

ConfigMapValidator no longer has an explicit ValidateDelete — the method is inherited from the embedded OwnedDeletionGuard. A reader searching for func (v *ConfigMapValidator) ValidateDelete will not find it.

2. The webhook calls `OwnedFinalizerOwner` on DELETE and rejects the request with a clear error (e.g., *"cannot delete 'rd': owned by App; delete the App resource instead"*).
3. When the owner wants to delete the child, it calls `RemoveOwnedFinalizer` first. The next DELETE passes the webhook because the finalizer is gone.

Without the webhook, a DELETE request is accepted by the API server and the resource enters Terminating — but the finalizer prevents actual deletion, leaving a stuck resource with no explanation. The webhook prevents this by rejecting the DELETE outright.

For an example, see `ConfigMapValidator.ValidateDelete` in the LimaVM controller, which protects template ConfigMaps owned by LimaVM resources.

Fix:

-For an example, see `ConfigMapValidator.ValidateDelete` in the LimaVM controller, which protects template ConfigMaps owned by LimaVM resources.
+For an example, see `ConfigMapValidator` in the LimaVM controller, which embeds `OwnedDeletionGuard` to protect template ConfigMaps owned by LimaVM resources.

OwnedFinalizerFor("") produces "rdd.rancherdesktop.io/owned-by-", which OwnedFinalizerOwner (line 264) parses back as "", causing HasOwnedFinalizer (line 258) to return false. The finalizer would exist on the resource but be invisible to all guards. Only one call site exists today (with a hardcoded string), so this cannot happen in practice, but a panic on empty input would surface a programming error immediately.

// OwnedFinalizerFor returns the owned finalizer name for a given owner Kind.
func OwnedFinalizerFor(ownerKind string) string {
	return ownedFinalizerPrefix + ownerKind
}

Fix (optional):

 func OwnedFinalizerFor(ownerKind string) string {
+	if ownerKind == "" {
+		panic("OwnedFinalizerFor: ownerKind must not be empty")
+	}
 	return ownedFinalizerPrefix + ownerKind
 }

Gemini argued that the invariant — "if the finalizer is present, the label must also be present" — should be enforced on the new state, not the old. Checking oldConfigMap blocks removing both the finalizer and the label in a single update (false rejection) and allows adding a finalizer without the label (missed rejection).

	if base.HasOwnedFinalizer(oldConfigMap) {
		if newConfigMap.Labels[controllers.TemplateConfigMapLabel] != "true" {
			return nil, fmt.Errorf("cannot remove %s label: resource is owned", controllers.TemplateConfigMapLabel)
		}
	}

Neither edge case is reachable in practice: the controller adds finalizers via EnsureOwnedFinalizer (the ConfigMap already has the label at that point) and removes them via RemoveOwnedFinalizer (never simultaneously removing the label). Checking oldConfigMap correctly expresses the stated intent: "while the resource is currently owned, protect the label." Checking newConfigMap would be more semantically precise about the resulting state but produces identical behavior for all reachable code paths. Either choice is defensible.

This allocates a new slice even when no owned finalizer is present. The function already returns false at line 284 if nothing was filtered, but the allocation still happens. Adding a quick HasOwnedFinalizer pre-check avoids the allocation in the common case. Minor — DeleteOwnedResources calls this only on owned resources, so the pre-check would rarely short-circuit.

func removeOwnedFinalizers(obj client.Object) bool {
	finalizers := obj.GetFinalizers()
	filtered := make([]string, 0, len(finalizers))
	for _, f := range finalizers {
		if !strings.HasPrefix(f, ownedFinalizerPrefix) {
			filtered = append(filtered, f)
		}
	}
	if len(filtered) == len(finalizers) {
		return false
	}
	obj.SetFinalizers(filtered)
	return true
}