hook and continuous image pullers' DaemonSets: configuring k8s ServiceAccount - yes or no?

[consideRatio]

trafficstars

Update

My take is that we should help people pass some compliance tests etc, even though it doesn't improve security in this case. There could be some edge case where use of service accounts can be relevant still, such as when PSPs were around or similar.

Background

There are two sets of machinery to pull images to k8s nodes:

• A temporary one-off machinery before helm upgrade proceeds in full using a pre-upgrade helm hook, referred to as "hook image pulling" or "hook pre-puller".
• A continiuous machinery after helm upgrade, referred to as "continous image pulling" or "continuous pre-puller"

Both involves a k8s DaemonSet to schedule a pod on each node, and have that pod startup containers referencing images to "pre-pull", which makes the k8s node's pull the images.

However, the hook image puller DaemonSet resource is paired with the hook-image-awaiter k8s Job, that in turn have misc permissions to inspect k8s DaemonSets - and by doing that can know if the pulling has completed. When pulling is completed, the pre-upgrade helm hook can be considered completed, and the helm upgrade command can proceed. This is why the hook-image-awaiter k8s Job needs a k8s ServiceAccount for itself, so it can be granted permissions to ask the k8s api-server about DaemonSet resources.

Question

• For the k8s DaemonSets resources created for the hook and continuous image puller machineries, is there a need to configure a k8s ServiceAccount by declaring a serviceAccountName?
• For the k8s DaemonSets resources created for the hook and continuous image puller machineries, is there a need to have the chart create a k8s ServiceAccount resource to use?