fix: add configurable automountServiceAccountToken

[stefan-caraiman]

This PR makes automountServiceAccountToken configurable for the deployment definitions.

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• README is updated with new configuration values (if applicable) learn more
• A PR is opened to update KEDA core (repo) (if applicable, ie. when deployment manifests are modified)

Fixes #

• configurable automountServiceAccountToken option in pod definitions

[JorTurFer]

Hello,
What is the goal of this change? I mean, this change suggests that the service account token is something optional, and it isn't. If you don't mount the service account tokens KEDA won't work as all the components have to interact with k8s api server.
Am I missing something?

[stefan-caraiman]

Hello, What is the goal of this change? I mean, this change suggests that the service account token is something optional, and it isn't. If you don't mount the service account tokens KEDA won't work as all the components have to interact with k8s api server. Am I missing something?

Hi there @JorTurFer ,

The change keeps the automountServiceAccountToken defaulting to true just as before.

It makes it configurable though for cases such as with Azure AKS Security policy which scans for any pod/deployments/SA that have it set to true and instead recommended as part of their security benchmarks to disable automounting and injecting the service account tokens as volumes explicitly for each workload that requires it: Kubernetes clusters should disable automounting API credentials

A similar thread on this from cert-manager and hardened values for such setups & rationale

For example in KEDAs cases this would be done as follows:

# Disable auto-mounting and inject it via volumes instead
automountServiceAccountToken: false

volumes:
  keda:
    extraVolumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: serviceaccount-token
      readOnly: true
    extraVolumes:
    - name: serviceaccount-token
      projected:
        defaultMode: 0444
        sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            name: kube-root-ca.crt
            items:
            - key: ca.crt
              path: ca.crt
        - downwardAPI:
            items:
            - path: namespace
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace

# Same extras for the following too
# volumes.webhooks.extraVolumeMounts
# volumes.webhooks.extraVolumes
# volumes.metricsApiServer.extraVolumeMounts
# volumes.metricsApiServer.extraVolumes

This same volume workflow is explained to be done by K8s ServiceAccount admission controller too when setting automountServiceAccountToken: true which still remains the default.

Hope this makes more sense on why it is helpful to make it configurable 😄

[stefan-caraiman]

@JorTurFer @tomkerkhove PTAL 👋

[JorTurFer]

I think that you should expect the rule directly in the Azure Security Center rather than "hacking" the rule. @tomkerkhove ?

[stefan-caraiman]

No harm in setting explicit definitions though, at least imo it seems more of a hack that the internal K8s admission controller does the volume mount of the tokens without the user being aware of it.

Nevertheless will leave it up to you to decide 👍

[JorTurFer]

I'm not directly against this tbh, but I'd like to see other folks thoughts.
@zroubalik @tomkerkhove ?

[stefan-caraiman]

@JorTurFer i will go ahead and close this PR in favour of #625 thanks