ArgoCD: Resolving CIS Compliance Issue with Non-Root User Requirement

Problem:

The client using Argo Workflows identified a compliance issue during a Twistlock (Prisma Cloud) scan. The image argoproj/argoexec:v3.7.1 failed the CIS Docker Benchmark 4.1 rule, which requires containers to run as a non-root user. Running containers as root posed a risk of privilege escalation and potential account takeover. The client wanted to resolve the issue and align with best practices while keeping workflows functional.

Process:

Step 1: Reviewing the Compliance Report

The expert analyzed the Twistlock report and confirmed that the problem was tied to the container image metadata. Although Argo Workflows allowed applying securityContext settings at runtime (e.g., runAsNonRoot: true and runAsUser: 8737), these changes did not pass the compliance scan because CIS 4.1 validation checks the Dockerfile, not the runtime configuration.

Step 2: Testing Security Context Options

The expert suggested adding security restrictions to Argo deployments using Helm or manifests. This included:

• runAsNonRoot: true
• runAsUser: 8737 (Argo default non-root UID)
• Disabling privilege escalation and dropping Linux capabilities

On OpenShift, however, these settings were overridden by Security Context Constraints (SCCs), which automatically assigned UIDs. While this improved runtime security, the compliance check still failed because the image itself was built to run as root.

Step 3: Evaluating Alternatives

The client explored Kubernetes User Namespaces (enabled by default in v1.33) to add isolation by mapping container root to a non-privileged user on the host. The expert explained that while this improved security posture, it still did not resolve CIS 4.1 compliance since the Dockerfile remained unchanged.

Step 4: Switching to a Non-Root Image

The expert identified that Argo provides a dedicated -nonroot image variant. By using argoproj/argoexec:v3.7.1-nonroot, the image metadata itself specifies a non-root user. This directly satisfies CIS 4.1 compliance and passes Twistlock scans.

The expert also clarified expected limitations:

• System directories such as /, /etc, /usr, /bin, and /var are not writable
• Writable locations include /tmp, /home/argo, mounted volumes, and workflow-created directories
• If workflows need access to restricted paths, initContainers can adjust permissions before execution

Solution:

The client adopted the argoproj/argoexec:v3.7.1-nonroot image along with a restricted securityContext. This ensured compliance with CIS Docker Benchmark 4.1 and enhanced runtime security. Key actions included:

• Switching to the -nonroot Argo image build
• Applying runAsNonRoot and runAsUser policies consistently
• Disabling privilege escalation and dropping unnecessary Linux capabilities
• Documenting expected limitations and providing workarounds for writable paths

Conclusion:

By moving to the -nonroot Argo image, the client successfully passed Twistlock compliance checks and aligned with the CIS Docker Benchmark 4.1 standard. The process highlighted the difference between runtime security settings and image-level compliance requirements. The solution not only satisfied audit needs but also strengthened overall container security posture, with minimal workflow disruption.