Why only kubernetes mode has a service account?

[shaul75]

actions-runner-controller/charts/gha-runner-scale-set/values.yaml

Lines 88 to 90 in d727747

	# kubernetesModeServiceAccount:
	# annotations:

Why not make it simply serviceAccount: {}, and have it work regardless of the mode?
We need it in dind mode, in order to assign an IAM role to the pod.

It seemed like it was more work and additional complexities to have the chart developed this way, so I'm trying to understand the rationale here.

[reda-ayoub]

same question here, @shaul75 did you figure out an alternative?

[shaul75]

@reda-ayoub I forked it and changed it

Here's a PR #3394

[nikola-jokic]

Hey @shaul75,

The reason is that the runner pod doesn't need to communicate with the k8s API in order to run a job. However, to run a job in k8s mode, the runner has to be able to talk to the k8s API. Running in kubernetes mode assumes that the default hook implementation is used, so we tried to provision the role, role binding and the service account for the ephemeral runner pod for you in advance.

However, if you need to modify something, you have complete control over the ephemeral runner spec. If defaults provided by the chart are insufficient for your use case, you can keep the container mode commented out, and provide the desired spec

[shaul75]

Thanks @nikola-jokic

The reason is that the runner pod doesn't need to communicate with the k8s API in order to run a job.

We do need to provide the runner pod with a service account with a specific annotation so that it can assume an IAM role, when running in EKS:

https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html

Name:                my-service-account
Namespace:           default
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
Image pull secrets:  <none>
Mountable secrets:   my-service-account-token-qqjfl
Tokens:              my-service-account-token-qqjfl

It's a common practice for charts to allow creating a service account and set annotations on it, but ARC doesn't allow it when it's not operating in Kubernetes mode.
Which means that when we use ArgoCD to deploy this chart, we have to somehow externally inject this service account resource, or fork the repository and add my simple modification #3394
Which then allows you to set:

serviceAccount:
  create: true
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role

My PR does not alter or break the current behavior, it allows users to additionally create this when needed. I assume it's not an uncommon use-case.