Restrict Cluster Role access authorizations

[orltom]

Component(s)

No response

Describe the issue you're reporting

Context Our current setup uses the OpenTelemetry Operator to make the application traceable. The operator is deployed through a Helm Chart. However, our Trivy scanner identifies that the operator has broad permissions via the Kubernetes ClusterRole.

Revise Based on my understanding, the OpenTelemetry Operator's current permissions allow it to delete various Kubernetes resources like pods, services, and service accounts. This level of access seems unnecessary for the operator's intended functionality.

The RBAC are generated via go maker comments. The most relevant ones are on the OpenTelemetryCollectorReconciler struct in the Reconcile function.

Suggestion

• For more granular access, define for each required Kubernetes kind access via +kubebuilder:rbac and do not group them in a single go comment marker.
• Remove delete access

Hint As these are cluster roles, this applies to all namespaces.

Version Helm Chart v0.58.2

[husnialhamdani]

I interested to work on this, can i get some details on which part I have to refactor?

[orltom]

Since I'm still familiarizing myself with the Operator codebase and associated Helm chart, I'd appreciate clarification on the following:

• Permissions: Can a main contributor explain why the Operator needs permissions to create and delete Pods, Services, and ServiceAccounts?
• Ingress Configuration: I noticed the OpenTelemetry CRD v1beta1 supports Ingress creation. Should this be handled within the operator or as part of the Helm chart deployment?
• RBAC and Helm Chart Synchronization: If changes are required to the RBAC manifests, how are these changes reflected in the Helm Chart repository? Are the main branches kept in sync?

After that I would also be prepared to help fix the issue. :)

[iblancasa]

• Permissions: Can a main contributor explain why the Operator needs permissions to create and delete Pods, Services, and ServiceAccounts?

• Pods: https://github.com/open-telemetry/opentelemetry-operator/issues/1679
• Services: to create the Services for the Collector (monitoring, collector service and headless service)
• ServiceAccounts: if no Service Account is provided, the operator creates one for the deployed OpenTelemetry Collector instance.

• Ingress Configuration: I noticed the OpenTelemetry CRD v1beta1 supports Ingress creation. Should this be handled within the operator or as part of the Helm chart deployment?

We prefer to handle this as part of the operator. Not everybody using the operator uses Helm to deploy. Also, it would involve more work on the Helm chart side.

• RBAC and Helm Chart Synchronization: If changes are required to the RBAC manifests, how are these changes reflected in the Helm Chart repository? Are the main branches kept in sync?

I think you should ask this in the Helm chart repository.

[pavolloffay]

discussed at SIG meeting:

• split the grouping +kubebuilder:rbac
• remove delete if it works (the stateful set might require delete in mutate.go)

A ticket should be opened at helm char repo to change the packaging - when installed in namespace more use the role instead of clusterrole.