Skip to content

Service accounts and rbac

Argo workflows

All the pods in a workflow use a service account. This service account can be specified with spec.serviceAccountName in the workflow. If not, uses the "default" service account (not recommended).

If using the argo cli, we can achieve that with the --serviceaccount NAME parameter

argo submit --serviceaccount myserviceaccount myworkflow

The minimum permissions to run workflows in newest releases (since 3.4) is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: executor
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: executor
rules:
  - apiGroups:
      - argoproj.io
    resources:
      - workflowtaskresults
    verbs:
      - create
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: executor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: executor
subjects:
  - kind: ServiceAccount
    name: executor
    namespace: argo

Depending of what the workflow has to do, it will neccesary to give that service account additional permissions via kubernetes rbac. For example, if the workflow creates pods, it will need the verb "create" in pods resource.

Using the http template

See the http template doc

In an Argo events sensor

If you want to create a workflow using an argo events sensor, you can pass the name of the service account (and other arguments) to the argo cli with the field "args" in addition to "source", "parameters" and "operation".