argoproj / argoproj/argo-workflows
Allow restriction of the workflowtemplate entrypoint
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
What change needs making?
I have a workflowtemplate, in which I intend two steps to be done:
Do something important for security, step `importantForSecurity` (in my case, something audit related), then do something else, step `stepb` (in my case patch a pod). The workflowtemplate looks like this:
```
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: my-workflowtemplate
namespace: default
spec:
serviceAccountName: myServiceAccount
entrypoint: main
templates:
- name: main
steps:
- - name: importantForSecurity
template: important-for-security
- - name: stepB
template: stepb
- name: important-for-security
(...)
- name: stepb
(...)
```
I would like to make sure, that step `importantForSecurity` is always run.
However, I can avoid running step `importantForSecurity` by specifying stepB as an entrypoint in the workflow using the workflowtemplate:
```
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: my-workflow-
namespace: default
spec:
serviceAccountName: myServiceAccount
entrypoint: stepB
workflowTemplateRef:
name: my-workflowtemplate
```
I have not seen any way to force using `main` as an entrypoint.
A solution may be a field allowedEntrypoints (list of strings) for the workflowtemplate spec. If set and not empty, only the listed templates may be used as entrypoints of the workflowtemplate.
E.g.:
```
allowedEntrypoints: [main, otherAllowedEntrypoint]
```
only allows templates `main` and `otherAllowedEntrypoint` to be used as an entrypoint.
# Use Cases
Anytime it is important to make sure specific steps are run in a workflowtemplate, e.g. for security reasons.
---
**Message from the maintainers**:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
Contributor guide
Research direction
Start by tracing how WorkflowTemplate entrypoint and workflowTemplateRef entrypoint values are validated and resolved. Compare the proposed allowedEntrypoints behavior with the main and stepB examples, then add focused coverage showing disallowed entrypoints are rejected while listed entrypoints still work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend-api-design, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100