Deep Review: 20260320-180916-pr-243

This text still says "strips their /owned finalizer" but the code now strips all owned-by-* finalizers via removeOwnedFinalizers. Since the PR updated surrounding documentation in the same section, this stale reference could have been caught.

## DeleteOwnedResources

`DeleteOwnedResources` finds all resources owned by a given object (via owner references), strips their `/owned` finalizer, and deletes them. It uses dynamic resource discovery to find all namespaced resource types without a hardcoded list.

For cluster-scoped owners, the resource must implement `ResourceNamespace` to specify which namespace contains its children.

Fix: change to "strips their owned-by-* finalizers."

The old ConfigMapValidator.ValidateDelete logged at V(1) during dry-run requests. The generic OwnedDeletionGuard.ValidateDelete ignores context entirely. The create/update paths still log dry-run via validateTemplateConfigMap at line 276, but the delete path no longer does. Low priority since it is V(1) debug logging.

// validateTemplateConfigMap validates the template data in a ConfigMap.
func (v *ConfigMapValidator) validateTemplateConfigMap(ctx context.Context, configMap *corev1.ConfigMap) (ctrlwebhookadmission.Warnings, error) {
	if base.IsDryRun(ctx) {
		klog.V(1).Infof("[DryRun] Webhook validating template ConfigMap %s/%s\n", configMap.Namespace, configMap.Name)
	}
	return validateTemplateData(ctx, configMap.Data)
}

Fix: accept context and add the dry-run log, for consistency with other webhook handlers.

By encoding the owner Kind in the finalizer name, this PR enables multiple controllers to maintain independent cascade protections. But removeOwnedFinalizers (called at line 168) strips all owned-by-* finalizers regardless of which owner triggered cleanup. If a resource ever has multiple owners, deleting one owner strips all ownership finalizers.

			// Strip owned finalizers to unblock deletion. The cleanup finalizer (if any)
			// remains so the child's own controller can still run its cleanup logic.
			patch := client.MergeFrom(item.DeepCopy())
			if removeOwnedFinalizers(&item) {
				// Use Patch instead of Update for PartialObjectMetadata
				if err := c.Patch(ctx, &item, patch); err != nil {
					itemLogger := logger.V(1).WithValues("namespace", item.GetNamespace(), "name", item.GetName(), "gvk", gvk.String())
					if apierrors.IsNotFound(err) {
						itemLogger.Info("Resource already deleted during finalizer removal")
						continue
					}
					// For other errors, log and collect error but proceed with deletion attempt
					// The deletion might still succeed if there are no other blocking finalizers
					itemLogger.Info("Failed to remove finalizer, will attempt deletion anyway", "error", err)
					errs = append(errs, fmt.Errorf("failed to remove finalizers from %s %s/%s: %w", gvk, item.GetNamespace(), item.GetName(), err))
				}
			}
			if err := c.Delete(ctx, &item); err != nil && client.IgnoreNotFound(err) != nil {

In RDD’s single-user embedded apiserver, multi-owner scenarios are unlikely, so this is a design note rather than a must-fix.

Fix: if multi-owner support becomes necessary, pass the owner Kind to DeleteOwnedResources and strip only the matching finalizer.

The validating webhook fires only for ConfigMaps with TemplateConfigMapLabel. A user who removes this label (via kubectl patch) and then deletes the ConfigMap bypasses the webhook entirely, leaving a stuck Terminating resource — exactly the failure mode the webhook exists to prevent.

	// Set up ConfigMap webhook for template ConfigMaps
	configMapWebhookConfig := base.WebhookConfig[*corev1.ConfigMap]{
		Name:        configMapValidatorConfigName,
		WebhookName: configMapValidatorWebhookName,
		WebhookPort: c.webhookPort,
		ObjectSelector: metav1apply.LabelSelector().
			WithMatchLabels(map[string]string{
				controllers.TemplateConfigMapLabel: "true",
			}),
		Operations: []admissionregistrationv1.OperationType{
			admissionregistrationv1.Create,
			admissionregistrationv1.Update,
			admissionregistrationv1.Delete,
		},
		Validator: &ConfigMapValidator{Client: mgr.GetClient()},
	}

In RDD’s single-user context this requires a deliberate two-step bypass, reducing practical risk. Broadening the webhook to match all ConfigMaps would add overhead for every ConfigMap operation in the namespace.

Fix: if this becomes a concern, either (a) reject label removal in ValidateUpdate when an owned finalizer is present, or (b) register the webhook for all ConfigMaps and return early for non-template ones.