BUG: Unnecessary permissions in charts

[Yseona]

Description

The bug is that the Deployment piraeus-operator-controller-manager in the charts has too much RBAC permission than it needs. The service account of piraeus-operator-controller-manager is bound to a clusterrole (rbac.yaml#L13) with the following permissions:

• update verb of the clusterrolebingdings resource (ClusterRole)
• patch/update verb of clusterroles/nodes resource (ClusterRole)
• create/patch/update/delete verb of the deployments/daemonsets/services resource (ClusterRole)
• create/patch/update verb of the pods resource (ClusterRole)
• list verb of the secrets resource (ClusterRole)

After reading the source code of piraeus-operator, I didn't find any Kubernetes API usages using these permissions. Besides, some of these unused permissions may have potential risks. For example, if malicious users gain control of a Kubernetes node running a piraeus-operator-controller-manager pod, they can use the create deployments permission to create privileged containers with malicious container images, or use the patch nodes permission to modify node specifications so that system-critical components with high privileges will run on the controlled node.

Therefore, these permissions should be rechecked to determine if they are truly unnecessary. If they are, the issue should be fixed by removing the unnecessary permissions or by using methods from some similar CVEs (e.g., CVE-2023-26484, CVE-2023-30840).

To Reproduce

Use helm charts with default values.

[WanzenBug]

You are right, most of them are excessive. We use kubebuilder to generate these RBAC from annotations in the code, and the default is to create cluster-scoped resources there. This can be changed, but is never called out in the relevant documentation.

We will work on reducing these permissions as much as possible.