Skip to content

fix(opentelemetry-operator): allow rbac subjectaccessreviews #1685

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Intuinewin
Copy link

@Intuinewin Intuinewin commented May 25, 2025

Hi,

The operator tries to create multiple SubjectAccessReview at startup in order to test rights and enable/disable features dynamically such as RBAC creation (cf this). Without this right all these features remain disabled.

Some error logs I was having:

{"level":"LEVEL(-2)","timestamp":"2025-05-25T19:34:46Z","logger":"config","message":"the rbac permissions are not set for the operator","reason":"unable to check rbac rules: subjectaccessreviews.authorization.k8s.io is forbidden: User \"system:serviceaccount:opentelemetry-operator:opentelemetry-operator\" cannot create resource \"subjectaccessreviews\" in API group \"authorization.k8s.io\" at the cluster scope"}

@Intuinewin Intuinewin requested review from Allex1, jvoravong and a team as code owners May 25, 2025 20:11
@jaronoff97
Copy link
Contributor

I do believe we want this still to only be allowed if kube rbac proxy is enabled (docs). is there a reason you have disabled the kube rbac proxy?

@Intuinewin
Copy link
Author

I don't understand what this has to do with the rbac proxy. I haven't enabled the rbac proxy because I don't need it. As far as I know, the proxy is used only to protect the operator's /metrics.

I agree that enabling the proxy in the chart would solve my problem but IMO the operator should be able to run with all its features enabled without requiring the rbac proxy.

Let me know if I'm missing something

@jaronoff97
Copy link
Contributor

ah i see what you mean... that makes sense to me. We do have an open issue for moving away from kube-rbac-proxy anyway, so i think this would be fine. If you could rebase the PR, i can ✅

@Intuinewin
Copy link
Author

Oh I wasn't aware of this issue. Thanks for your reply, I've updated the PR

@jaronoff97
Copy link
Contributor

waiting for tests to pass and then will merge, thank you for your patience 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants