Is it possible to create K8s resources via container or script template?

[maxsxu]

Currently, it seems only the resource template can perform operations on cluster resources directly.

Wondering would it possible to achieve this goal by container or script template like below:

  - name: create-resources-via-script-template
    script:
      image: bitnami/kubectl:latest
      command: [ sh ]
      source: |
        kubectl create ns argo

[terrytangyuan]

Yes you can run a script with kubectl create and kubectl wait.

[maxsxu]

@terrytangyuan Thanks for your confirmation!

However, occurred below errors while running a sample workflow:

create-resources-via-container-template: error: failed to create serviceaccount: Post "http://localhost:8080/api/v1/namespaces/default/serviceaccounts?fieldManager=kubectl-create&fieldValidation=Strict": dia
l tcp 127.0.0.1:8080: connect: connection refused

Here is the sample workflow:

metadata:
  name: create-resources-via-container-template
  namespace: argo
spec:
  executor:
    serviceAccountName: argo-executor
  serviceAccountName: argo-workflow
  automountServiceAccountToken: false
  entrypoint: main
  templates:
    - name: main
      container:
        name: main
        image: bitnami/kubectl
        command:
          - sh
        args:
          - -c
          - |
           kubectl create sa test

[maxsxu]

Not sure whether it is a bug or not.

Because the below workflow can work (without spec.automountServiceAccountToken and spec.executor.serviceAccountName):

metadata:
  name: create-resources-via-container-template
  namespace: argo
spec:
  serviceAccountName: argo-workflow
  entrypoint: main
  templates:
    - name: main
      container:
        name: main
        image: bitnami/kubectl
        command:
          - sh
        args:
          - -c
          - |
           kubectl create sa test

[terrytangyuan]

Could you submit an issue and include other necessary information?

[agilgur5]

It looks like #10937 was filed after this discussion and #10945 filed as a PR. But per #12848 (comment), this behavior was actually correct -- an SA token shouldn't be mounted to the main container when automountServiceAccountToken: false as you've literally instructed it not to. So the PR caused a regression as such.

If I'm reading correctly, it looks like in this discussion there was some confusion between serviceAccountName and executor.serviceAccountName -- #12848 (comment) describes how these are supposed to work, with the executor SA being specific to the Argo Executor's containers (init and wait) compared to your template's main container