Least Privileged RBAC ClusterRoles for controllers

[pjbgf]

Context:

• Flux creates a generic cluster-reconciler ClusterRole that is used across all controllers.
• The scope of some of the verbs and resources are set to * (a.k.a. all objects).
• Access to configMap and secret objects are granted at cluster-level to all controllers.

The points above make it difficult for users to understand exactly what level of permissions each controller requires.

Improvements for the current RBAC model:

• [ ] Create a ClusterRole per access profile and bind ClusterRole based on each controller's needs.
• [ ] Auto-generate ClusterRole's scope based on access requirements, minimising wildcard use for Verbs and Resources as recommended by CIS Benchmark.
• [ ] Create RFC to define access model in which Flux does not require cluster level access to sensitive objects (configMap and secret).

Some of the above could be automated via controller-gen-cli, allowing for the continuous update of the ClusterRoles as the access model changes over time.

[aryan9600]

I'll try to look into this. 👍

[stefanprodan]

We can't autogenerate RBAC for secrets/configmap, this would break Flux the moment you add a new namespace. I'm going to mark this as blocked as it needs a proper RFC.

[pjbgf]

@stefanprodan good point. I have changed the scope of the issue so that we can tackle the low hanging fruit items and create the RFC you suggested. Happy for us to go ahead or do you have any other concerns?

[stefanprodan]

I'm not for making as many ClusterRoles as controllers, we have a single ClusterRole now to make it easy for users to understand what Flux needs.

The points above make it difficult for users to understand exactly what level of permissions each controller requires.

How did you arrived at this conclusion, which users don't understand https://fluxcd.io/docs/security/#controller-permissions ? I see no issues on GitHub, no one reported this on Slack.

[pjbgf]

How did you arrived at this conclusion, which users don't understand https://fluxcd.io/docs/security/#controller-permissions ? I see no issues on GitHub, no one reported this on Slack.

Unfortunately, from a security standpoint users expect projects to be secure by default and to follow the least privilege principle. However, it is very difficult for users to do a deep security assessment on every single open source project they depend on to confirm and potentially raise issues to that effect.

The motivation for the above is to attain a reduced attack surface. At present, and in the documentation you mentioned above, we highlight our intention for only helm-controller and kustomization-controller to have privileges to deploy resources at cluster level (i.e. defaulting to cluster-admin ClusterRole). However, the current permission set does not align to that.

I'm not for making as many ClusterRoles as controllers, we have a single ClusterRole now to make it easy for users to understand what Flux needs.

Do you mind sharing your exact concerns on creating the least privileged permission model above? How do you see the changes above affecting users?