Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change operator cluster role to be read only by default #3569

Open
atoulme opened this issue Dec 21, 2024 · 2 comments
Open

Change operator cluster role to be read only by default #3569

atoulme opened this issue Dec 21, 2024 · 2 comments
Labels
enhancement New feature or request needs triage

Comments

@atoulme
Copy link
Contributor

atoulme commented Dec 21, 2024

Component(s)

auto-instrumentation

Is your feature request related to a problem? Please describe.

The operator cluster role as defined here:
https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/templates/clusterrole.yaml
This role gives write access to many objects across all namespaces.

Describe the solution you'd like

This should be kept down to a minimum of privileges:

  • Can it be filtered down to specific namespaces?
  • Can we document why the operator requires the right to, say, delete services?

Describe alternatives you've considered

No response

Additional context

No response

@atoulme atoulme added enhancement New feature or request needs triage labels Dec 21, 2024
@atoulme
Copy link
Contributor Author

atoulme commented Dec 28, 2024

I have shown it is possible to reduce rights of the operator greatly with https://github.com/otel-warez/whitegloves-operator

@swiatekm
Copy link
Contributor

swiatekm commented Jan 2, 2025

Can it be filtered down to specific namespaces?

Most likely yes. If we're ok without getting automatic RBAC for components, we don't need to create ClusterRoles, and all the other resources are namespaced. The operator already has an option to be scoped to a set of selected namespaces.

Can we document why the operator requires the right to, say, delete services?

We should, yes. There's been some discussion about this in #3156. The delete permissions exist for two reasons:

  • Sometimes resources are immutable, and we need to recreate them. Some changes to StatefulSets are like this. I think there's consensus that we should instead reject these kinds of changes and make the user recreate the whole Collector CR.
  • Some resources are optional, in that their existence depends on an attribute of the Collector CR. For example, whether we create ServiceMonitors for a Collector is like that. If the user disables it after enabling it in the past, we should delete it. We discussed this during the SIG meeting on 05.12.2024, and reached consensus that we're ok not making this deletion a condition of a successful reconcile. So, if the operator doesn't have the necessary RBAC for deletion, it'd log a warning, perhaps add a message to the resource status, and carry on.

In short, there's a path to let the operator work without delete permissions, if at the cost of some functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs triage
Projects
None yet
Development

No branches or pull requests

2 participants