4 ms·

The idea is nice, but if security is one of your concerns, you'll probably not want to run this if the docs are even close to representative of the actual appli

The idea is nice, but if security is one of your concerns, you'll probably not want to run this if the docs are even close to representative of the actual application: > 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'.

nrmitchi 8y ago
While I agree with your position that admin rights should not be the default, that doesn't seem to be what Argo is actually doing. 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.
- TheDong 8y ago
  The parent post did quality it appropriately with "if the docs are even close to representative of the actual application". 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.
  - jessesuen 8y ago
    Thanks. We've updated the docs to outline the bare minimum set of privileges.
tw04 8y ago
And right below that it says: >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. https://github.com/argoproj/argo/issues/725 https://github.com/argoproj/argo/issues/725
jessesuen 8y ago
I work on Argo. Those instructions are mainly for demo purposes because many of the examples need admin privileges. The amount of access which is needed, is really dependent on what your workflow is doing (e.g. if your workflow needs to deploy a resource, then you need to give the service account 'create' privileges on that resource). Currently, the bare minimum for a workflow to function is outlined here: https://github.com/argoproj/argo/issues/983#issuecomment-435541481 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.
- jessesuen 8y ago
  Docs have been updated and linked to in the getting started guide: https://github.com/argoproj/argo/blob/master/docs/workflow-rbac.md https://github.com/argoproj/argo/blob/master/docs/workflow-r...

nrmitchi 8y ago

While I agree with your position that admin rights should not be the default, that doesn't seem to be what Argo is actually doing. 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.

TheDong 8y ago
The parent post did quality it appropriately with "if the docs are even close to representative of the actual application". 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.
- jessesuen 8y ago
  Thanks. We've updated the docs to outline the bare minimum set of privileges.

tw04 8y ago

And right below that it says: >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. https://github.com/argoproj/argo/issues/725 https://github.com/argoproj/argo/issues/725

jessesuen 8y ago

I work on Argo. Those instructions are mainly for demo purposes because many of the examples need admin privileges. The amount of access which is needed, is really dependent on what your workflow is doing (e.g. if your workflow needs to deploy a resource, then you need to give the service account 'create' privileges on that resource). Currently, the bare minimum for a workflow to function is outlined here: https://github.com/argoproj/argo/issues/983#issuecomment-435541481 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.

jessesuen 8y ago
Docs have been updated and linked to in the getting started guide: https://github.com/argoproj/argo/blob/master/docs/workflow-rbac.md https://github.com/argoproj/argo/blob/master/docs/workflow-r...