Access to Archived Argo Workflows with Fake Token in `client` mode
Date: 2024-12
Affected: go/github.com/argoproj/argo-workflows/v3, go/github.com/argoproj/argo-workflows/v3
Attack vector: info-disclosure
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2024-53862
CWE: CWE-200

### Summary When using `--auth-mode=client`, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}` When using `--auth-mode=sso`, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}` ### Details No authentication is performed by the Server itself on `client` tokens[^1]. Authentication & authorization is instead delegated to the k8s API server. However, the [Workflow Archive](https://github.com/argoproj/argo-workflows/blob/52cca7e079a4f6d76db303ac550b1876e51b3865/server/workflowarchive/archived_workflow_server.go) does not interact with k8s, and so any token that [_looks_](https://github.com/argoproj/argo-workflows/blob/52cca7e079a4f6d76db303ac550b1876e51b3865/server/auth/mode.go#L37) [valid](https://github.com/argoproj/argo-workflows/blob/52cca7e079a4f6d76db303ac550b1876e51b3865/server/auth/gatekeeper.go#L185) will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does [the equivalent of a `kubectl auth can-i`](https://github.com/argoproj/argo-workflows/blob/52cca7e079a4f6d76db303ac550b1876e51b3865/server/workflowarchive/archived_workflow_server.go#L50) check for respective methods. In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow


Mitigations:

Architectural layers (MAESTRO):