rbac: Add view and edit aggregated cluster roles

[stefanprodan]

This PR adds two cluster roles which grant the Kubernetes view, edit and admin roles access to Flux custom resources.

Fix: #2409
Fix: #3572
Ref: fluxcd/kustomize-controller#762

[seh]

Is this still necessary? Back in August 2018 I learned from @deads2k that "view" aggregation is supposed to be included by "edit," and "edit" is supposed to be include by "admin" automatically.

[stefanprodan]

cert-manager and other controllers have these set. I guess it doesn't hurt to make this explicit so people reading the Flux RBAC understand what's going on.

[seh]

Is the idea with the "edit" and "admin" mutative rights that a user who has those roles granted in a given namespace could edit the target objects that Flux would reconcile, annotating or labeling them to disable Flux's coverage?

I was thinking at first that an administrator might want to retain full control over the Flux-related objects in a given namespace, in order to ensure that they continue projecting some required set of objects. However, I realized that other users with the "edit" or "admin" roles granted could still fight back against Flux, since it honors the "kustomize.toolkit.fluxcd.io/reconcile" annotation and label.

[stefanprodan]

@seh the admin/edit are for Flux impersonation, instead of creating a role binding to cluster-admin, the tenant service account could bind to admin and still be able to reconcile HelmRelease, Alerts, etc. The actual tenants shouldn't have edit rights to the cluster, all changes should be made in Git and Flux should apply them. I would grand tenants the view role only.

[seh]

The actual tenants shouldn't have edit rights to the cluster, all changes should be made in Git and Flux should apply them. I would gran[t] tenants the view role only.

I understand that intention. It so happens that in my organization we have a variety of tenants, some of which are engineers maintaining the applications that run within a given namespace. We have to allow them fairly liberal privileges to inspect and manipulate things, even if they like to use Flux as a convenient way to deploy similar changes to many Kubernetes clusters easily. In other words, in this model, Flux serves as assistive automation, as opposed to enforcement of policy.

[stefanprodan]

We have to allow them fairly liberal privileges to inspect and manipulate things, even if they like to use Flux as a convenient way to deploy similar changes to many Kubernetes clusters easily. In other words, in this model, Flux serves as assistive automation, as opposed to enforcement of policy.

Does this RBAC change prevents you from doing that?

[seh]

Does this RBAC change prevents you from doing that?

It makes it more likely that we'd accidentally grant broader privileges than we had intended, but if we really need to prevent that, we can delete these ClusterRoles with a kustomize patch when reconciling Flux's manifests, or patch them to remove the "aggregate-to-..." annotations.

[seh]

Thank you for this part of the documentation, @stefanprodan.