Add volumeMounts and volumes for createSecretJob and patchWebhookJob

[ababu13]

Add volumeMounts and volumes for createSecretJob and patchWebhookJob

In the job-createSecret.yaml and job-patchWebhook.yaml, there's an option to set the automountServiceAccountToken pointing to .Values.controller.admissionWebhooks.patch.serviceAccount.automountServiceAccountToken in the values.yaml file.

However, if we set the automountServiceAccountToken to false, the jobs will start to fail. By default it's true. Adding volumes and volumeMounts should help resolve this. In some cases, setting automountServiceAccountToken to false is required to fix some violations in Microsoft Azure Defender for cloud.

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Gacko]

Hello,

can you think of any reason why Microsoft Azure Defender is seeing a violation in not setting automountServiceAccountToken to false? Because I assume Microsoft is recommending that, because it is enabled by default and they further assume many many workloads do not need API server access by default. So they recommend setting it to false as you most likely do not need API server access.

This recommendation is definitely not meant as "disable the automation, set it up manually instead". It's meant as "disable automation for where you do not need it anyway". But since these jobs definitely need API server access, it does not make a difference if you disable the automation and set up the volumes manually or if you keep the automation enabled and let Kubernetes set up the volumes (which is ultimately the only difference when having automountServiceAccountToken enabled).

So I'd kindly ask you to overthink this "violation" instead of proposing a change to this project. I understand that there is not much sense in having automountServiceAccountToken configurable as long as there is no possibility to define the token otherwise. But if your main motivation is Microsoft telling you what to change in your application without checking why they do this, I'm having a hard time spending time on this.

Regards
Marco

[ababu13]

Hi Marco,

Thanks for the clarification. I understand your point that Microsoft’s recommendation to set automountServiceAccountToken to false is intended for workloads that don’t require API server access, and in this case, the jobs indeed do need it.

However, the issue here is that if someone explicitly sets automountServiceAccountToken to false, the pods will fail because the template doesn’t provide the required volume and volume mounts. My PR (#13811 ) addresses this by including the proper volume and volume mount configuration, ensuring that things continue to work even if automountServiceAccountToken is set to false.

By default, automountServiceAccountToken is already true, so explicitly setting it to true doesn’t change anything. Including the volume and volume mounts in the template would make the setup more robust, as it would handle both scenarios gracefully.

Given that, could this change be reconsidered for inclusion in the template?

Best regards,
Arjun