Generated ClusterRoleBinding doesn't have subjects.namespace defined

[andreaTP]

A default Controller generates the an invalid related ClusterRoleBinding.

e.g.:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: realmcontroller-cluster-role-binding
roleRef:
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
  name: realmcontroller-cluster-role
subjects:
  - kind: ServiceAccount
    name: keycloak-operator

This is not applicable to Kubernetes and it fails with:

The ClusterRoleBinding "realmcontroller-cluster-role-binding" is invalid: subjects[0].namespace: Required value

since the namespace is a mandatory field.

[metacosm]

Which version of the extension are you using? 2.0.3 should have fixes for this issue.

[andreaTP]

I'm using 3.0.0-SNAPSHOT

[andreaTP]

From the code: https://github.com/quarkiverse/quarkus-operator-sdk/blob/5119c1f817aa66b3f8583f7b26b2147a33a90e61/core/deployment/src/main/java/io/quarkiverse/operatorsdk/deployment/AddRoleBindingsDecorator.java#L83

this is still generating a null namespace in case I don't have a globally defined one (which I would like to avoid since people should be free to install without hassle to whatever namespace they prefer)

[metacosm]

There should be a warning in the console about this, no?

[andreaTP]

Yes there is a warning:

'realmcontroller' controller is configured to watch all namespaces, this requires a ClusterRoleBinding for which we MUST specify the namespace of the operator ServiceAccount. This can be specified by setting the 'quarkus.kubernetes.namespace' property. However, as this property is not set, we are leaving the namespace blank to be provided by the user by editing the 'realmcontroller-cluster-role-binding' ClusterRoleBinding to provide the namespace in which the operator will be deployed.

but we don't have a "realm" solution.

[metacosm]

That said if your operator only needs to watch a single namespace, you can configure it to simply watch the namespace in which it will be deployed and that should work…

[andreaTP]

The end goal is to deploy Cluster wide, but watching one namespace is useful for testing e.g.

[metacosm]

Then if it's for testing, people will know when deploying the namespace they want to watch and can therefore pass it via the quarkus.kubernetes.namespace property or am I missing something?

[andreaTP]

I want it to be easily customizable by end users.

But I think I found a "good enough" solution using kustomize this is the reference:

https://github.com/keycloak/keycloak/pull/9535/files#diff-4d0b1eae1d906945a05e18bb92e698ea12a17c092c169e6f665d556c552d9a2fR4-R24

which is:

• use an explicit namespace in kustomize

• use a replacement the subjects.[...].namespace field based on it

  
  namespace: keycloak

replacements:

• source: name: realmcontroller-jobs-role-binding kind: ClusterRoleBinding fieldPath: metadata.namespace targets:
  • select: name: realmcontroller-jobs-role-binding kind: ClusterRoleBinding fieldPaths:
  • subjects.[name=keycloak-operator].namespace

[metacosm]

Wondering if something like https://quarkus.io/guides/deploying-to-kubernetes#environment-variables-from-fields could be used for this… 🤔

[andreaTP]

I do believe that the end user of an operator will not even know that the operator runs on Quarkus and they just want to deploy it using some "standard" and agnostic Kubernetes tooling.

But the Quarkus extension can be useful during development for sure.

[metacosm]

Closing this as I believe it's addressed with the quarkus.operator-sdk.generate-with-watched-namespaces property. Please re-open if needed with additional details.