kubectl delete should fail if a non namespaced resource is about to get deleted with --all

[ViktorSchlaffer]

What happened:

An admin accidentally deleted all pv-s with the following command:
kubectl delete pv -n <some_namespace> --all

What you expected to happen:

Based on kubectl help, the expected behavior would be the following:

kubectl delete pv --all -> return an error / alternative behavior is to delete all pv, but in that case the help text for --all should be changed/
kubectl delete pv -n <namespace> --all -> return an error / or delete nothing, as we've scoped the request to a specific namespace
kubectl delete pv --all-namespaces --all -> delete all pv
kubectl delete pv -n <namespace> --all --all-namespaces -> delete all pv ( since --all-namespaces overrides -n according to the help)

Reasoning:
Cluster scoped resources are not namespaced.
The help for kubectl delete --help says the following about the --all , -A and -n parameters:

--all=false: Delete all resources, including uninitialized ones, in the namespace of the specified resource types.
-A, --all-namespaces=false: If present, list the requested object(s) across all namespaces. Namespace in current
context is ignored even if specified with --namespace.
-n, --namespace='': If present, the namespace scope for this CLI request

Therefore:
--all option alone shall not delete cluster scoped resources, as the help says that it deletes resources in a namespace, and cluster scoped resources are not namespaced.
Also, -n shall filter out all resources that are not in a given namespace. Cluster scoped resource is not in a namespace, so it should be filtered.

I know that kubectl delete is a GA command, and changing the behavior is a serious thing, but my proposal does not break valid scenarios, as a user is never supposed to scope to a namespace when deleting cluster scoped resources.
This proposal is valid for similar scenarios, like this similar issue that mentions accidental delete of namespace: #1056

How to reproduce it (as minimally and precisely as possible):
Example:
kubectl delete pv -n <namespace> --all

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:45:53Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}

[k8s-ci-robot]

@ViktorSchlaffer: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[eddiezane]

We're hoping to address this via https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3104-introduce-kuberc. You can see that and this thread for the history https://groups.google.com/g/kubernetes-dev/c/y4Q20V3dyOk.

/close

kubernetes/enhancements#3104

[k8s-ci-robot]

@eddiezane: Closing this issue.

In response to this:

We're hoping to address this via https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3104-introduce-kuberc. You can see that and this thread for the history https://groups.google.com/g/kubernetes-dev/c/y4Q20V3dyOk.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.