Submitting from a WorkflowTemplate shows incorrect serviceAccount and securityContext nag

[tyrken]

Summary

Starting a Workflow from a WorkflowTemplate brings up the security nag "This workflow does not have security context set. ..." - even if the WorkflowTemplate defines a securityContext. I've also (just) noticed that the serviceAccount is also shown as "default" even though I'm running with one (currently having to as using PNS).

What version of Argo Workflows are you running?

Running with v3.2.7 client & v3.2.6 server

Diagnostics

Example WorkflowTemplate

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: my-workflow-template
  namespace: my-namespace
spec:
  entrypoint: main
  securityContext:
    runAsNonRoot: false
  serviceAccountName: my-service-account
  templates:
    - name: main
      metadata:
      container:
        command:
          - bash
          - -c
          - echo 'Hello from WT'; env; sleep 15
        image: ubuntu
        name: main

Example command & output:

$ argo submit --from workflowtemplate/my-workflow-template
Name:                my-workflow-template-76qt4
Namespace:           my-namespace
ServiceAccount:      default
Status:              Pending
Created:             Tue Feb 01 21:38:02 +0000 (now)
Progress:            

This workflow does not have security context set. You can run your workflow pods more securely by setting it.
Learn more at https://argoproj.github.io/argo-workflows/workflow-pod-security-context/

What Kubernetes provider are you using? EKS

What executor are you running? PNS

---

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

[tyrken]

I can only assume the test at

argo-workflows/util/printer/workflow-printer.go

Line 117 in 81afc8a

if wf.Spec.SecurityContext == nil {

and access at

argo-workflows/cmd/argo/commands/get.go

Line 121 in 1159afc

serviceAccount := wf.Spec.ServiceAccountName

are operating on the "raw" spec. I was expecting some accessor function which merged the WorkflowTemplate into the Workflow before letting code query object attributes...

[alexec]

@tyrken this is a CLI problem?

@sarabala1979 can I check my logic here? If you have wf.Status.StoreWorkflowSpec, you should use that, otherwise use wf.Spec? I wonder if we should add a wf.GetExecSpec()?

[alexec]

@tyrken I think you've found the bug, do you want to fix it? I think we'd benefit from a func named:

func (w *Workflow) GetExecSpec() *WorkflowSpec

That would return w.Status.StoredWorkflowSpec or w.Spec and then you could just call that.

[sarabala1979]

yes cli should use wf.GetExecSpec()

[sarabala1979]

Dillen is going submit the PR for this

[tyrken]

I think it is a CLI only issue, and thanks-in-advance to Dillen!

[sarabala1979]

Yes it is a CLI issue. Dillen will fix it

…

Sent from my iPhone

On Feb 5, 2022, at 7:24 AM, Tristan Keen ***@***.***> wrote:  I think it is a CLI only issue, and thanks-in-advance to Dillen! — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.