STRIMZI_RBAC_SCOPE not working ?

[Pavelsky89]

Hi all,

I have a need of setting up strimzi operator on several namespaces in my k8s. I want these deployments to be completely isolated from each other. To achieve it, I need to get rid of ClusterRoles created as part of strimzi operator deployment.

I found an enhancement under #3826, there is even regular pull request merged for it. Hoewer, the thing is, that setting this envar to NAMESPACE doesn't seem to do anything. Is my understanding of this feature incorrect, or am I missing something else?

[scholzj]

You cannot get rid of the Cluster Roles and it was never possible. You can not create the ClusterRoleBindings - and if you don't use some features that need them, it will work fine. E.g. node port listeners or rack awareness. You do not need to set anything special. Just deploy it without the ClusterRoleBindings and do not use the features that need them.

[Pavelsky89]

Thank you for response

Let me add a bit more context. I'm trying to utilize GitOps approach for our deployments, meaning that every time new branch is created, a new namespace in k8s is created with strimzi operator within it, in isolation from other namespaces. When I try to install strimzi operator in second namespace via below cmd:

helm install my-strimzi-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator

it gives me below below error:

Error: rendered manifests contain a resource that already exists. Unable to continue with install: ClusterRole "strimzi-cluster-operator-namespaced" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-namespace" must equal "feature_branch_experimental_2": current value is "feature_branch_experimental_1"

Since I cannot get rid of ClusterRoles, how can I instruct strimzi to reuse existing cluster roles?

Any advices are much appreciated.

[scholzj]

Strimzi does not have problem with re-using the ClusterRoles. The error you get is from Helm. But in general, I do not think your approach scales. Kubernetes is not really multitenant - especially when it comes to operators - and apart from ClusterRoles, there are many other resources such as CRDs. So if you just blindly install Strimzi around, you will probably soon have also conflicts between different versions etc. So much better way is to install Strimzi once, have it watch the whole cluster and deploy only the Kafka clusters per-namespace.

[Pavelsky89]

Thanks for reply. I think deploying operator once for all namespaces seem to be best idea in my situation, considering CRDs too.
But still, do you have any clue why helm doesn;t allow to install operator twice ?

[scholzj]

I'm not a Helm user. But my understanding is that it keeps tracking some kind of ownership and the error basically tells you that this resource is owned by some other Helm Chart installation. No idea if you can work around it somehow.

In the Strimzi Helm Chart, there is a flag createGlobalResources that skips installation of the resources that are not namespaces. It expects them to be installed separately out of band (i.e. they are still needed, but the Helm Chart does not create them). Not sure if this can help in any way as you would need to somehow manually keep them up to date.

(PS: Helm also does not update CRDs, so that needs to be done separately as well.)

[Pavelsky89]

All right, thanks for answer