protect clusternet auto-generated resources don't be deleted

[DanielXLee]

What would you like to be added:

Prevent users from deleting intermediate resources created by clusternet

When deploying an application from a hub cluster, clusternet will automatically generate some intermediate resources, such as base, description, and helmrelease, and we do not want users to delete these resources directly.
Users only need to pay attention to the resources they create, such as manifest, helmchart, and subscription.

Why is this needed:

If the user deletes these intermediate resources, the application will be recreated in the sub-cluster, which is destructive for some applications.

[dixudx]

Prevent users from deleting intermediate resources created by clusternet

IMO this is feasible by granting appropriate RBAC rules.

[DanielXLee]

We encountered a problem, the HelmRelease and Description resources were recreated, which caused the Helm Chart on our child cluster to be uninstalled, but the corresponding Base resources did not change. Do you have any suggestions for this situation?

☁  ~  kubectl get base -A -l 'apps.clusternet.io/subs.name=internal'
NAMESPACE          NAME       AGE
clusternet-7h4kn   internal   153d
clusternet-jjpr4   internal   153d
clusternet-ls8v8   internal   153d
clusternet-r7zwk   internal   131d
☁  ~  kubectl get description -A -l 'apps.clusternet.io/subs.name=internal'
NAMESPACE          NAME            DEPLOYER   STATUS    AGE
clusternet-7h4kn   internal-helm   Helm       Success   7d5h
clusternet-jjpr4   internal-helm   Helm       Success   7d5h
clusternet-ls8v8   internal-helm   Helm       Success   7d5h
clusternet-r7zwk   internal-helm   Helm       Success   7d5h
☁  ~  kubectl get hr -A -l 'apps.clusternet.io/subs.name=internal'
NAMESPACE          NAME                                               CHART              VERSION   REPO                                      STATUS     AGE
clusternet-7h4kn   internal-helm-clusternet-system-clusternet-agent   clusternet-agent   0.11.1    oci://ccr.ccs.tencentyun.com/tdccimages   deployed   7d5h
clusternet-jjpr4   internal-helm-clusternet-system-clusternet-agent   clusternet-agent   0.11.1    oci://ccr.ccs.tencentyun.com/tdccimages   deployed   7d5h
clusternet-ls8v8   internal-helm-clusternet-system-clusternet-agent   clusternet-agent   0.11.1    oci://ccr.ccs.tencentyun.com/tdccimages   deployed   7d5h
clusternet-r7zwk   internal-helm-clusternet-system-clusternet-agent   clusternet-agent   0.11.1    oci://ccr.ccs.tencentyun.com/tdccimages   deployed   7d5h

[DanielXLee]

These resources were not artificially removed

[dixudx]

the HelmRelease and Description resources were recreated

How come? In Clusternet controllers, these objects will not be recreated, but only be updated or deleted.

[DanielXLee]

Under normal circumstances, the creation time of Base, Description, and HelmRelease should be the same, but in our environment, it is obvious that Description and HelmRelease were deleted at a certain point in time

[DanielXLee]

What kind of scene can trigger the controller to delete all Descriptions?

[dixudx]

What kind of scene can trigger the controller to delete all Descriptions?

When a Subscription gets deleted, all the Descriptions referring the Subscription will be deleted in cascading.

[DanielXLee]

The truth is, the subscription is not deleted

[DanielXLee]

IMO this is feasible by granting appropriate RBAC rules.

These intermediate resources may be accidentally deleted by some unaware administrator users. We have added a deletion protection mechanism to better protect applications in sub-clusters from being deleted. @dixudx RBAC rules cannot restrict admin users.