pepov
commented
1 month ago The logging operator manages RBAC for the underlying fluentbit daemonset, because fluentbit requires ClusterRole to access the Kubernetes API for pod metadata to attach to log records.
Also the operator uses those RBAC just not explicitly but through the https://github.com/cisco-open/operator-tools project where it creates/reads/updates/deletes resources in a declarative manner by just passing objects to that library that handles changes as needed, example: https://github.com/kube-logging/logging-operator/blob/9e5947470619592f261089f56b5311eea949f0c6/pkg/resources/fluentbit/fluentbit.go#L149
In case you need a stricter set of rules I would recommend to reach out for commercial support
The bug is that the Deployment logging-operator in the charts has too much RBAC permission than it needs. The service account of
logging-operatoris bound to a clusterrole (clusterrole.yaml) with the following permissions:updateverb of theclusterrolebindingsresource (ClusterRole)patch/updateverb of theclusterrolesresource (ClusterRole)create/patch/update/deleteverb of thedeployments/statefulsets/daemonsets/replicasets/servicesresource (ClusterRole)deleteverb of theingressesresource (ClusterRole)create/patch/updateverb of thejobsresource (ClusterRole)patch/updateverb of thepodsresource (ClusterRole)After reading the source code of logging-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
logging-operatorpod, they can use thecreate deploymentspermission to create privileged containers with malicious container images.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 or other feasible methods.
To Reproduce
Use the helm charts with default values.