Configure the service account to run Workflows¶
Roles, Role-Bindings, and Service Accounts¶
In order for Argo to support features such as artifacts, outputs, access to secrets, etc. it needs to communicate with Kubernetes resources
using the Kubernetes API. To communicate with the Kubernetes API, Argo uses a
ServiceAccount to authenticate itself to the Kubernetes API.
You can specify which
Role (i.e. which permissions) the
ServiceAccount that Argo uses by binding a
Role to a
ServiceAccount using a
Then, when submitting Workflows you can specify which
ServiceAccount Argo uses using:
argo submit --serviceaccount <name>
ServiceAccount is provided, Argo will use the
ServiceAccount from the namespace from which it is run, which will almost always have insufficient privileges by default.
For more information about granting Argo the necessary permissions for your use case see Workflow RBAC.
Granting admin privileges¶
For the purposes of this demo, we will grant the
ServiceAccount admin privileges (i.e., we will bind the
Role to the
ServiceAccount of the current namespace):
kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default -n argo
Note that this will grant admin privileges to the
ServiceAccount in the namespace that the command is run from, so you will only be able to
run Workflows in the namespace where the
RoleBinding was made.