fix: Replace wildcards in RBAC objects with explicit resources and verbs

[legal90]

According to Kubernetes documentation and various k8s security guidelines, wildcards in resource and verb entries should be avoided:

[!WARNING] Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources. For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable. The principle of least privilege should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied.

Refs:

• https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
• https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac#no-wildcards

This PR could be seen as a continuation of a previous work for hardening the RBAC: https://github.com/kedacore/charts/pull/625 It replaces * with explicit verbs and resources, according to KEDA needs.

Checklist

• [x] I have verified that my change is according to the deprecations & breaking changes policy
• [x] Commits are signed with Developer Certificate of Origin (DCO - learn more)
• [x] README is updated with new configuration values (if applicable) learn more
• [x] A PR is opened to update KEDA core (repo) (if applicable, ie. when deployment manifests are modified)

Similar PR to the main keda repo: https://github.com/kedacore/keda/pull/6129

[JorTurFer]

This PR look nice, but we can revert if by mistake during the release if we copy the RBAC from KEDA repo. Could you open a PR there too, changing the RBAC? 🙏

[legal90]

Thank you, @JorTurFer ! I submitted the similar PR to the main KEDA repo: https://github.com/kedacore/keda/pull/6129

[JorTurFer]

It was a CI problem, the fix is merged and I've rebased your PR

[qlikcoe]

@JorTurFer @zroubalik Will this break a scenario when horizontal-pod-autoscaler ServiceAccount's token was used for connecting to the Datadog Cluster Agent?

As per KEDA's documentation:

Bearer authentication:

token - The ServiceAccount token to connect to the Datadog Cluster Agent. 
The service account needs to have permissions to get, watch, and 
list all external.metrics.k8s.io resources.

UPD Nevermind. There is another ClusterRole called datadog-cluster-agent-external-metrics-reader that's also attached to the horizontal-pod-autoscaler SA and that role has all the neccessary RBAC rules.