[archived] "Manually Create ServiceAccount Secrets" docs discussion

[giscus[bot]]

argo-workflows/manually-create-secrets/

https://argoproj.github.io/argo-workflows/manually-create-secrets/

[SebastianGoeb]

The generated pod specs already have a projected token mount in them:

  volumes:
    # ...
    - name: kube-api-access-58ntg
      projected:
        defaultMode: 420
        sources:
          - serviceAccountToken:
              expirationSeconds: 3607
              path: token
          # ...

which seems to be the official way forward, if I understand K8s correctly. Apparently, we should all be using these projected volumes, whereby the token is taken directly from the API server and also rotated, instead of being persisted in a long-lived Secret and mounted from there.

However, if I specify a serviceAccountName and executor.serviceAccountName (which we need to do in order to authorize only the main container as a specific identity), then the pod spec also includes an "old fashioned" mount for exec-sa-token. Is that really necessary? I would have assumed that all ServiceAccount tokens can be handled via projected volume instead of secret mount.

[agilgur5]

This page is linked to from the SSO RBAC docs, which is very different from Executor RBAC. SSO can use multiple SAs (depending on who logs in) and does not run a new Pod, so the requirements are very different.

I see that this doc actually doesn't mention it's for SSO though; that should be fixed.

[SebastianGoeb]

Okay thanks, so if I understand this right, then the "proper way" is to have a joint SA for the whole pod (exec and main container) that is bound to a role with workflowtaskresults create/patch, but no pod patch. Especially because K8s doesn't reeeally support per-container SAs. If for whatever reason, one does want per-container SAs, then the only way to do it is to mount directly from secrets because a projected volume can't specify which SA to use. It's always the SA of the pod.

[agilgur5]

More or less, yes. SAs are indeed Pod-level, not container-level, and so some (less than ideal) workarounds are necessary due to that.