AutomountServiceAccountToken property implemented

[ph311o]

Added new property "automountServiceAccountToken" in ServiceAccounts and Deployments necessary for restricted environments.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• README is updated with new configuration values (if applicable)

Fixes #

[tomkerkhove]

Did a quick review, thanks for the change!

@zroubalik Do you want to have these changes in our generated YAML files?

[JorTurFer]

Hey,
I'm looking for information about this feature and I can't find any clear use case (or most probably, I'm not understanding them).
Could you explain your use case?

[ph311o]

@JorTurFer Hi. Our UseCase is as follow:

In general Kubernetes automounts service account credentials which allows any compromised pod to run API commands against the cluster. We are restricted to stop this behaviour by specifying automountServiceAccountToken: false in ServiceAccount. This is a global rule so we cannot whitelist the helm chart.

As Keda and metrics deployments/pods need API access we need to opt in for these two with automountServiceAccountToken: true in both deployment.yamls

When you set both ServiceAccount and Deployments automountServiceAccountToken: true it's the same like not specifying at all so I am not sure if it makes sense to specify it in the installation.yaml. We need it in Helm Chart as said to disable default ServiceAccount behaviour and ensure functionality.

Also see:

• Kubernetes should not mount default service account credentials by default kubernetes/kubernetes#57601
• https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2022/06_APP_Anwendungen/APP_4_4_Kubernetes_Edition_2022.pdf;jsessionid=831EB9783FD3996CD80511A21925E8EE.internet482?__blob=publicationFile&v=3#download=1

[JorTurFer]

I got the reasons (I don't understand the document in German but I guess that it's an official regulation).
In this case, what is the difference between having automountServiceAccountToken true or false in the service account if we are only using it for deployments?
I mean, maybe this is a non-optional improvement, if the behavior is the same just disabling it at service account and enabling them in deployments... @kedacore/keda-helm-contributors ?

[ph311o]

@JorTurFer Do you need more informations from my side or do we wait for more opinions by other maintainers? In general you can disable it in ServiceAccount and enable it in Deployments hardcoded. But then everybody who would use the Keda ServiceAccount perhaps for other deployments could not longer access API. This was the reason why I decided to implement a switch in values.yaml for ServiceAccount.

[zroubalik]

I think it is okay to have an optional switch, ie. default to the existing behavior.

[JorTurFer]

I think it is okay to have an optional switch, ie. default to the existing behavior.

So we can merge this PR because it keeps the current behaviour as default behaviour, can't?

[ph311o]

@JorTurFer Yes absolutely it keeps current behaviour. Would be great if anybody could merge it for next release. Thank you.

[tomkerkhove]

Would love to have a sign-off of @zroubalik or @JorTurFer as well though

[JorTurFer]

F**k, I missed this PR between the notifications :(
If the behavior doesn't change, I don't have any problem to merge it

[tomkerkhove]

Thank you @ph311o and sorry for being slow on our end!