Fine-tuning service account namespace

[MikeEdgar]

We can currently give the service account's namespace using quarkus.kubernetes.namespace, but this also results in the namespace being added everywhere to the generated Kubernetes resources. It would be useful to be able to also use quarkus.kubernetes.rbac.service-accounts.my-service-account.namespace=my_namespace as the primary lookup, then fall-back to quarkus.kubernetes.namespace.

Aside - while looking at AddRoleBindingsDecorator, I noticed that the service account name is based on the deployment name. If the deployment has its own serviceAccountName already, it is ignored for the role binding, but still used in a generated CSV for the deployment.

[metacosm]

Note that you can already use the quarkus.operator-sdk.generate-with-watched-namespaces property to tell QOSDK the name of the target namespace where your operator would be deployed, though I guess we could look up the Quarkus property as well.

[metacosm]

Though, there do appear to be some discrepancy, indeed, since it doesn't seem like that property is being used in AddRoleBindingsDecorator… 🤦🏼

[MikeEdgar]

Would quarkus.operator-sdk.generate-with-watched-namespaces help with the operator's own service account? I could be missing what that property is meant to be used for.

[metacosm]

Let me check the service account name part but no, the QOSDK property won't help with that, it will only help with specifying which namespaces will be used to generate the manifests, more specifically, which namespaces will be watched by the operator once deployed (if known).

[metacosm]

Aside - while looking at AddRoleBindingsDecorator, I noticed that the service account name is based on the deployment name. If the deployment has its own serviceAccountName already, it is ignored for the role binding, but still used in a generated CSV for the deployment.

Could you actually clarify the scenario you have in mind here? The service account name that's used in the manifests is the one coming from the kubernetes extension generated manifests so it should be consistent unless I'm missing something?

[MikeEdgar]

Suppose I use quarkus.kubernetes.rbac.service-accounts.my-service-account.namespace=my_namespace to set the service account/namespace for an operator where the deployment name is my-operator. In the generated CSV the operator deployment's serviceAccountName is my-service-account, but the serviceAccountName in the RBAC section is my-operator, which seems to be based on the deployment's name [1].

If support for quarkus.kubernetes.rbac.service-accounts.my-service-account.namespace=my_namespace is added, it might be necessary to look at the deployment's serviceAccountName and not the metadata.name. wdyt?

[1] https://github.com/quarkiverse/quarkus-operator-sdk/blob/main/core/deployment/src/main/java/io/quarkiverse/operatorsdk/deployment/AddRoleBindingsDecorator.java#L51

[metacosm]

If you generate a my-service-account SA, wouldn't it be the name used in your operator's deployment, though? How would the link between both be made?

[MikeEdgar]

If you generate a my-service-account SA, wouldn't it be the name used in your operator's deployment, though? How would the link between both be made?

Yeah, that's what happens, but AddRoleBindingsDecorator creates the permissions for a service account named after the deployment, not my-service-account.