[JENKINS-68673] Do not mount Jenkins container volumnes on Job containers

(Created a public ticket after a vulnerability was reported as SECURITY-2149 but considered by the maintainers as a feature)

The plugin checks for `containerId.isPresent()`, then tries to mount all volumes mounted on the Jenkins container on the new Job container.

This is exactly what I want to prevent since it poses a huge attack surface for untrusted code.

https://github.com/jenkinsci/docker-workflow-plugin/blob/1089131014350e11adfa364d34e7717954350261/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L168

Suggestion: make this behaviour configurable.

Some comments from the ticket:

On the Jenkins agent container. Which should be considered untrusted, and running in an isolated daemon for example in an agent VM. (If you run builds on the controller, or share a daemon between controller and agents, you might as well just disable security.)

I agree that the behavior should be made configurable, and that it should be disabled by default for the Jenkins controller.

There are use-cases when it potentially makes sense to allow controller volume mapping, e.g. in Jenkinsfile Runner executions which cannot be considered "trusted" due to their architecture (same as agent).

---
Originally reported by tomlankhorst, imported from: Do not mount Jenkins container volumnes on Job containers

• status: Open
  
• priority: Minor
  
• component(s): docker-workflow-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 2025-12-07
  

(Created a public ticket after a vulnerability was reported as SECURITY-2149 but considered by the maintainers as a feature)




The plugin checks for `containerId.isPresent()`, then tries to mount all volumes mounted on the Jenkins container on the new Job container.


This is exactly what I want to prevent since it poses a huge attack surface for untrusted code.


https://github.com/jenkinsci/docker-workflow-plugin/blob/1089131014350e11adfa364d34e7717954350261/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L168


Suggestion: make this behaviour configurable.


Some comments from the ticket:


On the Jenkins agent container. Which should be considered untrusted, and running in an isolated daemon for example in an agent VM. (If you run builds on the controller, or share a daemon between controller and agents, you might as well just disable security.)


I agree that the behavior should be made configurable, and that it should be disabled by default for the Jenkins controller.


There are use-cases when it potentially makes sense to allow controller volume mapping, e.g. in Jenkinsfile Runner executions which cannot be considered "trusted" due to their architecture (same as agent).