This way users can make use of these roles by having them
aggregated into the 'view', 'admin' and 'edit' ClusterRoles
present on Kubernetes clusters by default.
Without these roles you would have to bind subjects in a confined
Namespace to the `cluster-admin` ClusterRole which lets them create
cluster-scoped resources. To really confine subjects to a single
Namespace you would rather want to bind them to the `admin` or `edit`
ClusterRole so that they cannot create cluster-scoped resources. This
is where these new ClusterRoles created in this commit come into play,
letting subjects bound to one of these two ClusterRoles created Flux
CRDs such as HelmRelease or Kustomization.
Signed-off-by: Max Jonas Werner <mail@makk.es>
Readonly access to namespaces is needed by the
image-reflector-controller to support the cross-namespace accessFrom
functionality introduced in image-reflector-controller#162.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
The v0.8.0 version of the controller-runtime uses both config maps and
leases to perform leader election. These permissions seem to be in the
individual controller repos, but not here. For example
2d38de8779/config/rbac/leader_election_role.yaml (L33-L44)
Signed-off-by: Brian Atkinson <brian@atkinson.mn>
During high custom resource count / low interval tests, I was greated
with a `cannot patch resource "events"` message. This happened due to
event compaction, where it will perform a patch instead of a create.
By giving the role the permission to do so this should no longer pose
a problem.
