search

quarkiverse / quarkus-operator-sdk

Quarkus Extension to create Kubernetes Operators in Java using the Java Operator SDK (https://github.com/java-operator-sdk/java-operator-sdk) project
Apache License 2.0
118 stars 50 forks source link

Fine-tuning service account namespace #932

Open MikeEdgar opened 3 weeks ago

MikeEdgar commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

MikeEdgar commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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.