Introduction

If an Argo Workflow keeps running under the namespace default service account, the usual cause is that the workflow spec never sets serviceAccountName, or the value is being overridden by workflow defaults. The fix is normally in the workflow manifest and RBAC configuration, not in the container image or the template commands.

Where the Service Account Is Chosen

For Argo Workflows, the pod service account is typically controlled at the workflow spec level:

1apiVersion: argoproj.io/v1alpha1
2kind: Workflow
3metadata:
4  generateName: hello-
5spec:
6  entrypoint: main
7  serviceAccountName: argo-runner
8  templates:
9    - name: main
10      container:
11        image: alpine:3.20
12        command: ["sh", "-c"]
13        args: ["echo hello"]

If serviceAccountName is missing, Kubernetes falls back to the namespace default service account for the workflow pods.

Create the Service Account and Bind Permissions

Setting the name alone is not enough. The account must exist and have the permissions the workflow actually needs.

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: argo-runner
5  namespace: workflows
6---
7apiVersion: rbac.authorization.k8s.io/v1
8kind: Role
9metadata:
10  name: argo-runner-role
11  namespace: workflows
12rules:
13  - apiGroups: [""]
14    resources: ["pods", "pods/log"]
15    verbs: ["get", "list", "watch"]
16---
17apiVersion: rbac.authorization.k8s.io/v1
18kind: RoleBinding
19metadata:
20  name: argo-runner-binding
21  namespace: workflows
22subjects:
23  - kind: ServiceAccount
24    name: argo-runner
25roleRef:
26  apiGroup: rbac.authorization.k8s.io
27  kind: Role
28  name: argo-runner-role

Without the RBAC binding, the workflow may start with the right account but still fail later when it tries to call the Kubernetes API.

Check Workflow Defaults and Submission Paths

If the manifest already sets serviceAccountName and Argo still uses default, inspect the workflow controller configuration and any workflow template defaults. Some installations apply defaults centrally, which can override or inject fields during submission.

Practical checks:

• inspect the submitted workflow object
• inspect the generated pod spec
• inspect the workflow controller config map

If the live workflow resource does not contain your expected service account, the override happened before pod creation.

Verify the Generated Pods

Do not stop at the workflow YAML. Confirm what Kubernetes actually created.

kubectl get workflow -n workflows hello-abcde -o yaml
kubectl get pods -n workflows -o yaml

Look for serviceAccountName in the workflow spec and then in the pod spec. That tells you whether the wrong value came from submission, controller defaults, or pod-generation behavior.

WorkflowTemplate and CronWorkflow Cases

The same rule applies to WorkflowTemplate and CronWorkflow. The service account belongs in the workflow spec section that eventually becomes the runtime workflow.

1apiVersion: argoproj.io/v1alpha1
2kind: CronWorkflow
3metadata:
4  name: nightly-job
5spec:
6  schedule: "0 2 * * *"
7  workflowSpec:
8    serviceAccountName: argo-runner
9    entrypoint: main
10    templates:
11      - name: main
12        container:
13          image: alpine:3.20
14          command: ["sh", "-c"]
15          args: ["date"]

If you place the field in the wrong section, Argo will ignore it and Kubernetes will still fall back to default.

Common Pitfalls

The most common mistake is assuming Argo will infer a non-default service account automatically. It will not unless you configure it explicitly.

Another issue is creating the service account but forgetting the role binding. That changes the identity but does not grant the required permissions.

A third problem is setting serviceAccountName in a template fragment or parent config that does not actually control the runtime workflow spec.

Summary

• Argo uses the namespace default service account when serviceAccountName is not set.
• Put serviceAccountName in the workflow spec that drives pod creation.
• Create the service account and bind the RBAC permissions it needs.
• Inspect the submitted workflow and generated pods to see where the wrong value appears.
• Check controller defaults and template structure if your explicit setting is being ignored.