Open brouberol opened 3 months ago
Hi @brouberol
Everything that you say is true and yes it's a good idea, but there's some on going work on the operator side to reduce the amount of permissions required, we already removed a lot of permissions, but sadly, there's some permissions that will require to be ClsuterRoleBinding, like the one require for the nodes information, since the resources nodes
aren't namespaced resources.
Some PRs are being created, if you can create one to make the Helm operator work namespaced will be awesome!
Thanks in advance!
Hi @sxd! I'll be experimenting with tweaks at the RBAC level. When I'm sure everything is working properly, I'll send out a PR to leverage Role
and RoleBinding
resources where possible!
Thanks for reaching back quickly 🙏
As the chart is currently setup, it is relying on
ClusterRole
andClusterRoleBinding
resources to grant the operator CRUD permissions cluster-wide, to allow it to manage its associated resources in any namespaces in which its custom resources are created. However, one might argue that this is a lot of permissions to grant cluster-wideAfter the reading the operator code, I realized that the operator can be passed a
WATCH_NAMESPACE
environment variable containing a comma-separated list of namespaces to watch. If we exposed that namespace list as a chart value (e.g.$.Values.watchedNamespaces
), we could then loop over it, and createRole
andRoleBinding
resources scoped to each namespace and the operatorServiceAccount
. As a result, I believe that the operator would still work as expected, but would only have permissions to act on the configured namespaces, instead of the whole kubernetes cluster.I'm happy to hear your thoughts.