Summary

The workflow-role has excessive privileges, the worst being create pods/exec, which will allow kubectl exec into any Pod in the same namespace, i.e. arbitrary code execution within those Pods. If a user can be made to run a malicious template, their whole namespace can be compromised.

This privilege was used by the k8sapi Executor in older Argo Workflows versions <=3.3 when selected. In versions >=3.4, only the Emissary Executor is available, and it does not use any forms of elevated privileges. See also a summary of the Executors in an older version of the docs: https://argo-workflows.readthedocs.io/en/release-3.4/workflow-executors/.

This was resolved by #3044

Details

The workflow-role has excessive privileges:

pods/exec and pods/log

• pods/exec is not needed.
  • Upstream, only the Controller uses this when necessary to enforce timely termination
  • In Argo Workflows versions <=3.3, the pods/exec permission could be used by the k8sapi Executor. In versions >= 3.4, Emissary is the only Executor and it does not use this privilege.
• pods/log is not needed.
  • Upstream, only the Server uses this to retrieve logs for workflow Pods for displaying via the API, CLI, UI.
  • In Argo Workflows versions <=3.3, the pods/log permission could be used by the k8sapi Executor. In versions >= 3.4, Emissary is the only Executor and it does not use this privilege.
• pods is not needed.
  • Upstream, the Controller and the Server use this to manipulate child Pods
  • In Argo Workflows versions <=3.3, the Executor would use patch and get pods. In versions >= 3.4 though, these permissions were replaced with create and patch workflowtaskresults. The upstream code could also fallback to patch pod with a deprecation warning, although the upstream manifests no longer included this. In >=3.6, the legacy fallback will be removed.
  • Only the k8sapi Executor would use watch

PoC

Install per instructions with a Workflow SA:

helm repo add argo https://argoproj.github.io/argo-helm
helm install my-release argo/argo-workflows -f values.yaml

# values.yaml
workflow:
  serviceAccount:
    create: true
    name: "argo-workflow"
  rbac:
    create: true
controller:
  workflowNamespaces:
    - default

Run Workflow that execs into the Controller

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-in-controller-
spec:
  entrypoint: controller-exec
  serviceAccountName: argo-workflow # Set ServiceAccount
  templates:
    - name: controller-exec
      container:
        image: bitnami/kubectl
        command: [ kubectl ]
        args: 
          - exec
          - workflow-controller
          - echo
          - "hello world"

Impact

Anyone who uses the provided workflow-role may be vulnerable to arbitrary code execution from a malicious template.

The role is currently installed by default. Fortunately though, the attached SA is not installed by default and would still have to be manually added as a serviceAccountName to a Workflow or template.

This affects versions of the argo-workflows Chart that use appVersion: 3.4 and above, which no longer need these permissions for the only available Executor, Emissary. It could also affect users below 3.4 depending on their choice of Executor in those versions.