Helm hooks don't use the specified service account, is that correct?

[Jurrie]

Hi everyone,

I stumbled upon something I find weird. But since I'm new to all this stuff, I'd thought I'd ask here before filing a bug report 😀

I have a Helm chart which I deploy using Flux. The HelmRelease object has a .spec.serviceAccountName set. That Helm chart installs okay.
But the Helm chart also has a pre-upgrade hook (which is basically just a Job). So when I want to upgrade my chart, that hook should run. It seems the service account I set on the HelmRelease object is not used for the hook..? The pod that's spun up in the hook is using the default service account.
When I "manually" edit the hook, and I set .spec.template.spec.serviceAccountName to be my service account, the hook works!

I'd rather not have my specific service account be present in a generic Helm chart. Different clusters could use different service account names. I feel that should be specified in Flux' HelmRelease object only...

Is this the correct behavior? If so, why? What's the reason for not using the specified service account for Helm hooks? Can I specify it in the HelmRelease object using a different property maybe?

Thanks!

[stefanprodan]

The HelmRelease .spec.serviceAccountName has nothing to do with the account under which workloads run, the Flux SA is used to apply the Kubernetes objects, we never alter their definitions.

[Jurrie]

Aah, right. So I guess that all the things in my Helm charts have used the default SA all along. But since my hook needs to do things that the default SA can not do, I'm suddenly running into it. Right, thanks for your answer!