Kubernetes Client: Use the correct service account name

[Sgitario]

When not setting any name, the extension will use the current resource name which is not a correct logic (as there could have additional resources from users).

Fix #25688

[Sgitario]

Reported issue on Dekorate side: dekorateio/dekorate#987
I've also provided the fix there.

[Sgitario]

/cc @geoand, @iocanel, @edeandrea

[edeandrea]

@Sgitario Is there a config option to tell the extension not to generate a role binding/service account? In my case I'm providing the RoleBindings myself via the user-provided yamls & I don't necessarily want to create new service accounts.

[Sgitario]

@Sgitario Is there a config option to tell the extension not to generate a role binding/service account? In my case I'm providing the RoleBindings myself via the user-provided yamls & I don't necessarily want to create new service accounts.

At the moment, there is no config option to disable this.
The rbac manifests generation is triggered by the kubernetes-client extension (see

quarkus/extensions/kubernetes-client/deployment/src/main/java/io/quarkus/kubernetes/client/deployment/KubernetesClientProcessor.java

Line 75 in 6b03da0

roleBindingProducer.produce(new KubernetesRoleBindingBuildItem("view", true));

).
Therefore, we could easily add a new property to not do so if disabled.
Would this make sense to you? cc @edeandrea @iocanel ?

[edeandrea]

Yeah I think that would make sense, at least for my use case. The default could be to do what is being done today, but if disabled, don't generate a role binding or service account.

[Sgitario]

Yeah I think that would make sense, at least for my use case. The default could be to do what is being done today, but if disabled, don't generate a role binding or service account.

Okis. I will create a separate pull request to add a new property that disables the rbac generation.
PR: #25756

[edeandrea]

Thanks @Sgitario !

[geoand]

@iocanel can you take a look at this please?

Thanks

[edeandrea]

Hi any progress on this one?

[iocanel]

LGTM

[iocanel]

While I can see how this pull request fixes: #25688, I feel that the issue description indicates that when existing resources are used some things are performed possibly out of the expected order. This is something that we may want to track, as it's likely we'll encounter that in the future.

[edeandrea]

Hey @Sgitario I just tried this out for the first time and I don't think the behavior is correct. When I generate I can see the ServiceAccount is created, but if I have other existing Deployments or DeploymentConfigs within my src/main/kubernetes files it is applying the service account to ALL of the resources rather than JUST the resource its supposed to.

For example, looking at https://github.com/quarkusio/quarkus-super-heroes/blob/main/rest-fights/src/main/kubernetes/openshift.yml you'll notice there are 3 Deployments listed (apicurio, fights-kafka, and fights-db).

When I generate openshift.yml with the updated kubernetes-client extension, the resulting target/kubernetes/openshift.yml the rest-fights ServiceAccount, but that service account is applied to ALL of the other Deployments. It should only be applied to the DeploymentConfig for rest-fights.

I would think this is a problem still. I need to use quarkus.kubernetes-client.generate-rbac=false to suppress this.

[Sgitario]

Hey @Sgitario I just tried this out for the first time and I don't think the behavior is correct. When I generate I can see the ServiceAccount is created, but if I have other existing Deployments or DeploymentConfigs within my src/main/kubernetes files it is applying the service account to ALL of the resources rather than JUST the resource its supposed to.

For example, looking at https://github.com/quarkusio/quarkus-super-heroes/blob/main/rest-fights/src/main/kubernetes/openshift.yml you'll notice there are 3 Deployments listed (apicurio, fights-kafka, and fights-db).

When I generate openshift.yml with the updated kubernetes-client extension, the resulting target/kubernetes/openshift.yml the rest-fights ServiceAccount, but that service account is applied to ALL of the other Deployments. It should only be applied to the DeploymentConfig for rest-fights.

I would think this is a problem still. I need to use quarkus.kubernetes-client.generate-rbac=false to suppress this.

I've changed this behavior in this pull request: #26558
Let's continue the discussion there.