Deploying Operator with customized/restricted RBAC

[xtherebellion]

Hi there,

I am evaluating using this operator in an environment where I can't actually deploy RBAC resources. RBAC must be deployed separately from the helm chart, so I've set rbac.create: no, and I've compiled all of the permissions here.

However I am seeing errors in the operator logs for reading and creating roles. Is there a way to create all of the expected roles separately and not have the operator manage any RBAC? (I understand the simplicity/value in having the operator do this, however in this environment it's simply not possible)

[scholzj]

The operator creates the roles in some cases in order to provide minimal required access for the operands where required. In theory, you could precreate the roles with the right names to avoid the operator needing the CREATE RBAC. But you cannot block it from managing the roles. The rbac.create flag in the Helm Chart is really only about the installation. It has no impact on the operator at runtime.

(Frankly, not wanting to give the operator access to the namespaced RBAC resources is highly unusual - I think you are the first one. Usually if there is something what needs to be created out-of-band, it is only the cluster-scoped RBAC resources.

[xtherebellion]

Thanks @scholzj , I definitely agree with you that these requirements are not normal for K8s, unfortunately for this project, I don't have much choice.

I just want to confirm, when you say block it from managing roles, you mean that even if the roles are defined, it needs to be able to patch/update them, and probably create rolebindings? In other words, if I can't give these permissions to the operator, it's a hard blocker?

[scholzj]

Honestly, I never tried it. If the role exists and has the correct configuration, the GET right might be sufficient. The general logic looks something like this:

• Get the role to see if it already exists
• If it does not exist, create it
• If it exists, compare the current role with desired and decide if it needs patching
• Either patch it, or do nothing

So the GET right will be needed in any case. The CREATE and PATCH/UPDATE rights might not be needed if you create it manually with the right values. Please don't ask me what the right values are as I do not know it our of my head 😉 -> best try it on Minikube or Kind and copy what it creates there -> the Strimzi labels etc. would need to be reused as well, likely also owner references, etc. -> But you would need to try it.

I also want to make it clear that even if you get it working this way, we might not be able to guarantee it will always work. I guess the planned ServerSideApply support might change things and so on.