You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
I have searched existing issues and could not find a match for this bug
We are using templateReferencing: Secure configuration in our argo workflows in order to limit the calls to workflowTemplates only.
We have discovered that when using the podSpecPatch field and overriding the container image and commands you can practically override this setting to execute any arbitrary workflow you want.
Also, the UI shows that the container image and command are the original ones, although in reality it runs the overridden image and commands
Version(s)
v3.6.0-rc1
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1kind: Workflowmetadata:
generateName: workflow-template-hello-world-spec:
workflowTemplateRef:
name: workflow-template-submittable# No matter what image you had in the template it gets overridenpodSpecPatch: | containers: - name: main image: busybox command: [echo] args: ["hello world"]
michaelncy
changed the title
Using podSpecPatch with strict mode can override container image and command
Using podSpecPatch with templateReferencing: Secure mode can override container image and command
Nov 7, 2024
michaelncy
changed the title
Using podSpecPatch with templateReferencing: Secure mode can override container image and command
Using podSpecPatch with templateReferencing: Secure mode can still override container image and command
Nov 7, 2024
Pre-requisites
:latest
image tag (i.e.quay.io/argoproj/workflow-controller:latest
) and can confirm the issue still exists on:latest
. If not, I have explained why, in detail, in my description below.What happened? What did you expect to happen?
We are using
templateReferencing: Secure
configuration in our argo workflows in order to limit the calls to workflowTemplates only.We have discovered that when using the podSpecPatch field and overriding the container image and commands you can practically override this setting to execute any arbitrary workflow you want.
Also, the UI shows that the container image and command are the original ones, although in reality it runs the overridden image and commands
Version(s)
v3.6.0-rc1
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: