REDHAT-BUG-2510327: High severity Kubernetes API server vulnerability
Finding The v2 compiler (backend/src/v2/compiler/argocompiler/securitycontext.go) forcibly applies PSS-restricted defaults to every container it generates. The kubernetesexecutorconfig proto explicitly removed privileged/addcapabilities/dropcapabilities. All of this is bypassed when a tenant uploads a document whose TypeMeta matches argoproj.io/v1alpha1 / Workflow: the API server unmarshals it into a full workflowapi.Workflow struct and creates it via its own ServiceAccount (which holds workflows: create). The Argo workflow-controller then materializes pods containing whatever the tenant wrote: spec.templates[].container.securityContext.privileged: true, spec.hostNetwork: true, spec.hostPID: true, spec.volumes[].hostPath.path: /, arbitrary initContainers, and spec.serviceAccountName.
Files:
backend/src/apiserver/template/template.go:62-67 — inferTemplateFormat routes any V1 document
backend/src/apiserver/template/template.go:153-157 — NewArgoTemplate
backend/src/apiserver/template/argotemplate.go:209-230 — ValidateWorkflow runs structural lint only, no security-context filtering
backend/src/apiserver/template/argotemplate.go:30-91 — RunWorkflow deep-copies user spec verbatim
Framework: OWASP K8s K01/K02; ASVS V5.2.5 CWE: CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine) / CWE-668 (Exposure of Resource to Wrong Sphere) CVSS v3.1: 7.6 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L) – High
Confused-Deputy Aspect The pipeline submitter need not hold create workflows or use scc/privileged. The ml-pipeline SA creates the Workflow on their behalf, and the workflow-controller SA creates the Pod. Whether the pod is admitted depends solely on namespace SCC/PSA. In RHOAI data-science-project namespaces that bind GPU operators or anyuid/privileged SCC for CUDA workloads, this yields node-root.
Verification Confirmed that the V1 path is still reachable in RHOAI/DSPO deployments:
DSPO passes no flags or env vars to disable V1 template handling
The Argo CRD deployed by DSPO registers v1alpha1 as served:true and storage:true
No DSPA CR field, operator config, or feature flag restricts template formats
Impact A namespace editor can achieve node-root by uploading a raw Argo Workflow with hostPath, hostNetwork, privileged:true via the V1 API path. The API server creates the Workflow CR as a confused deputy.
Remediation Disable the V1 Argo template path in RHOAI builds (feature flag, fail inferTemplateFormat to V1 with NewInvalidInputError)
If V1 must remain, add a sanitizer in RunWorkflow/ValidateWorkflow that strips hostPath/hostNetwork/hostPID/hostIPC, forces securityContext.privileged=false, drops capabilities, and clears serviceAccountName
Operator-side: ensure DSP namespaces carry pod-security.kubernetes.io/enforce: restricted and that pipeline-runner SA is not bound to privileged/anyuid SCC
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In RHOAI builds, disable the V1 Argo template path by failing inferTemplateFormat when a tenant supplies a V1 template, returning NewInvalidInputError (feature flag).
RHOAI (DSPO) Argo template handling V1 Argo template path feature flag / inferTemplateFormat behavior = Disable V1 template handling (fail inferTemplateFormat to V1 with NewInvalidInputError) - Configuration
If V1 must remain, add a sanitizer in RunWorkflow/ValidateWorkflow that removes hostPath/hostNetwork/hostPID/hostIPC from the tenant workflow, forces spec.securityContext.privileged=false, drops capabilities, and clears serviceAccountName before creating the Workflow CR.
Argo API server (RunWorkflow/ValidateWorkflow) Workflow specification sanitization = Strip hostPath/hostNetwork/hostPID/hostIPC; set securityContext.privileged=false; drop capabilities; clear serviceAccountName - Configuration
Ensure DSPO namespaces carry pod-security.kubernetes.io/enforce: restricted so that pods generated by the workflow-controller cannot be admitted with privileged/host* configuration.
RHOAI DSPO namespace Pod Security Admission pod-security.kubernetes.io/enforce = restricted - Configuration
Ensure the pipeline-runner service account (ml-pipeline SA that creates the Workflow) is not bound to privileged/anyuid SCC, since admission depends on namespace SCC/PSA.
RHOAI pipeline-runner service account SCC bindings (e.g., privileged/anyuid) = Not bound to privileged/anyuid SCC - Compensating control
Recreate/resubmit affected pipelines after applying the fixes, and ensure the resulting pods are admitted under the restricted policy; pods materialized from previously submitted workflows may otherwise retain node-root configuration.
Event History
Frequently Asked Questions
What is the severity of REDHAT-BUG-2510327?
The severity of REDHAT-BUG-2510327 is high with a score of 7.
What are the risks associated with REDHAT-BUG-2510327?
The risk associated with REDHAT-BUG-2510327 involves the improper application of PSS-restricted defaults leading to potential security vulnerabilities in container configurations.
How do I fix REDHAT-BUG-2510327?
To fix REDHAT-BUG-2510327, ensure that the Kubernetes executor configurations explicitly adhere to the correct security context settings by restricting privileges appropriately.
Which software is affected by REDHAT-BUG-2510327?
The affected software includes the Kubernetes API server and Argo Workflows with the v1alpha1 Workflow.
What specific aspect of containers does REDHAT-BUG-2510327 address?
REDHAT-BUG-2510327 addresses the default application of PSS-restricted settings in containers generated by the v2 compiler.