workflowRestrictions Should Not Effect Cron Workflow Adhoc Runs

[sstaley-hioscar]

Pre-requisites

• I have double-checked my configuration
• 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
• I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?

For the record I lied on the above prerequisites because they didn't apply. I also did not test on latest because this setting is only true on our more locked down higher environments where I cannot arbitrarily change the service version.

When attempting to submit a cron workflow adhoc, I am unable to do so when workflowRestriction is set.

I don't know if this is a bug report or a feature request, but to me it seems like a bug. IMO the "purpose" of requiring template referencing is to ensure all workflow runs are gated by version control (given that you only allow workflow templates to be created via git/CICD).

running a cron adhoc should serve the same purpose of requiring a workflow to be defined via a resource in the cluster prior to the run.

Version(s)

v3.5.8

Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.

Any cron workflow should do.

Logs from the workflow controller

N/A

Logs from in your workflow's wait container

N/A

[tczhao]

This is by design.
This helps to prevent users from submitting arbitrary workflows.

Cronworkflow also needs to use templateRef in their spec such that below workflow is not allowed

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  timezone: "America/Los_Angeles"   # Default to local machine timezone
  startingDeadlineSeconds: 0
  concurrencyPolicy: "Replace"      # Default to "Allow"
  successfulJobsHistoryLimit: 4     # Default 3
  failedJobsHistoryLimit: 4         # Default 1
  suspend: false                    # Set to "true" to suspend scheduling
  workflowSpec:
    entrypoint: hello-world-with-time
    templates:
      - name: hello-world-with-time
        container:
          image: busybox
          command: [echo]
          args: ["🕓 hello world. Scheduled on: {{workflow.scheduledTime}}"]

[sstaley-hioscar]

Hi @tczhao, I do understand the intent that "This helps to prevent users from submitting arbitrary workflows."

My argument, as stated in the original ticket is that "running a cron adhoc should serve the same purpose of requiring a workflow to be defined via a resource in the cluster prior to the run.".

A cron workflow has to exist before it can be submitted, exactly like a workflow template.

You cannot submit an arbitrary workflow if you're doing so by submitting a cronjob. And, these workflows are themselves submitted by the controller without a template reference, so I don't think your argument has much merit.

I think this was an oversight/unintended consequence of the design, and should require another look.

[sstaley-hioscar]

Am I missing some detail that would make it possible for a person to submit arbitrary workflow using a cron?