feat(helm): reduce scope of rbac permissions and introduce usage of RoleBinding

[lukidzi]

Motivation

To improve security, we are introducing a new option that allows the use of RoleBinding instead of ClusterRoleBinding. The default ClusterRoleBinding will also have reduced access to cluster resources.

Implementation information

• Permissions in the default ClusterRole have been reduced.
• The default ClusterRole is now split into:
  • A cluster-scoped role for and read only namespaced.
  • A namespaced role for read and write access within specified namespaces.
• Users can now provide a list of namespaces that are part of the Mesh. When this is configured, we create RoleBindings in those namespaces instead of a single ClusterRoleBinding.

Warning

kubelinter recommend usage of explicit resource names instead of * in ClusterRole. At the moment I've disabled this validator since we want to watch all kuma resources and avoid changes to ClusterRole. Let's discuss if we want to use * with disabled linter or we should explicitly set them.

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources

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.

Supporting documentation

Fix #13371

[github-actions]

Reviewer Checklist

🔍 Each of these sections need to be checked by the reviewer of the PR 🔍:
If something doesn't apply please check the box and add a justification if the reason is non obvious.

• Is the PR title satisfactory? Is this part of a larger feature and should be grouped using > Changelog?
• PR description is clear and complete. It Links to relevant issue as well as docs and UI issues
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as an image registry)
• IPv6 is taken into account (.e.g: no string concatenation of host port)
• Tests (Unit test, E2E tests, manual test on universal and k8s)
  • Don't forget ci/ labels to run additional/fewer tests
• Does this contain a change that needs to be notified to users? In this case, UPGRADE.md should be updated.
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label)

[lukidzi]

@bartsmykla We don't need after #13409 ?