[FEATURE] Enhance RBAC security

[ChenYi015]

Community Note

• Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

What is the outcome that you are trying to reach?

1. Adhering to the principle of least privilege is a best practice in Kubernetes RBAC. Spark operator now has a ClusterRole with overly board permissions which can lead to security risks:

spark-operator/charts/spark-operator-chart/templates/rbac.yaml

Lines 66 to 84 in 6ded3ac

	- apiGroups:
	- apiextensions.k8s.io
	resources:
	- customresourcedefinitions
	verbs:
	- create
	- get
	- update
	- delete
	- apiGroups:
	- admissionregistration.k8s.io
	resources:
	- mutatingwebhookconfigurations
	- validatingwebhookconfigurations
	verbs:
	- create
	- get
	- update
	- delete

2. As descriped in Uninstall the chart cannot delete all kubernetes resources associated with that release #1959, the resources cannot be deleted completely after uninstalling the chart, because the RBAC resources are created by Helm hooks.

Describe the solution you would like

• Create a ClusterRole for the Spark operator in the release namespace, and create a Role in every namespace where Spark applications are deployed. The ClusterRole should grant permissions to cluster scoped resources such as Node and Lease, while the Role should grant permissions for namespaced resources like SparkApplication, Pod, ConfigMap, and Event.

• The RBAC resources for the spark operator should managed by helm, not helm hooks.

• Create a ServiceAccount, ClusterRole, and Role specifically for the Spark operator webhook. These should be created by Helm pre-install and pre-upgrade hooks, and should be deleted after the completion of these hooks.

• MutatingWebhookConfiguration and ValidatingWebhookConfiguration should be managed by Helm hooks, not spark operator.

Describe alternatives you have considered

Additional context