>NOTE: You can also submit workflows which run with a different service account using:
>argo submit --serviceaccount <name>
To which there is further documentation as to the exact permissions you need. While I only spent about 30 seconds searching, this gets you 90% of the way there from what I can tell on my phone.
The text snippet you've included is from the quick start/demo page, which seems to be targeted at getting the examples running quickly so that a potential user can see what it is capable of. Other issues for this in a production setup would be the use of the 'default' role/namespace at all. In this use case (running the examples in a new cluster), giving the default user full access is the quickest way to this result.
Clearly it would be better if Argo included a more precise (permission wise) role by default, but from my understanding Argo does not require cluster admin permissions in order to function.
I hope the docs are not representative, but the parent post is right that it's a bad sign. At least put up a warning sign that it's insecure and only suitable for demo purposes to do that.
https://github.com/argoproj/argo/issues/983#issuecomment-435...
I will make sure that the docs are updated, so that this information is well understood.
> 3. Configure the service account to run workflows
> For clusters with RBAC enabled, the 'default' service account is too limited to support features like artifacts, outputs, access to secrets, etc... Run the following command to grant admin privileges to the 'default' service account in the namespace 'default'
This raises so many red flags. Never give admin rights 'as a default'.