argoproj / argoproj/argo-workflows
Change executor default service account from `default` to `workflow` to avoid accidentally over-permissioning
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
Today, if a workflow does not specify a service account, we use the default service account. Because the default service account maybe used for many things, it is likely we see many additional privileges added to it over time - until it becomes god like.
Users should never use the default service account in production.
Instead:
- [ ] Print a warning in the controller when the default service account is used.
- [ ] Print a warning in the CLI when the default service account is used.
- [ ] Print a warning in the UI when the default service account is used.
- [ ] Allow a configuration of the default account to use in the controller configmap. Provide a minimal `serviceaccount/workflow` (role and role-binding).
- [ ] Change the defaulte configuration of the default account to be `serviceaccounts/workflow`.
# Use Cases
Improve default security posture.
---
**Message from the maintainers**:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
Contributor guide
Research direction
Start by locating the controller, CLI, and UI paths that select or report the workflow service account, plus the controller ConfigMap and existing service-account role manifests. Trace the current defaulting behavior and review how warnings and RBAC resources are represented. Done means all listed warnings, configurable defaulting, minimal workflow permissions, and the new default are implemented and verified across those components.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, cli, devops, frontend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100