Drop potentially unexpected privilege escalation from RBAC docs

In the docs there is an example for the usage of RBAC with flux. The example permissions aren't just broad, but broader than what's recommended as a general best practice, imposing an unexpected risk for the unknowledgable user.

The section in question in this one:

https://github.com/fluxcd/kustomize-controller/blob/def45c50b3a418d1a11032acd86bedee82ac2995/docs/spec/v1beta2/kustomization.md?plain=1#L485-L508

The permissions of the Role are unnecessarily broad and might grant more access to the reconciler than users with access to this namespace might have. E.g. by allow the modification of resource quotas, which are a namespaced resource and therefore covered by this role.

Instead I would suggest to use the default admin role in this role binding in order to keep privileged in line with what one expects from someone with "full access" to a namespace.

The resulting YAML would collapse into a single RoleBinding:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: webapp-reconciler
  namespace: webapp
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: ServiceAccount
    name: flux
    namespace: webapp

References: https://kubernetes.io/docs/concepts/security/rbac-good-practices/#escalate-verb

fluxcd / kustomize-controller

Drop potentially unexpected privilege escalation from RBAC docs #762