Details
-
Epic
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Incomplete
-
2.0 Security, Split GUI, Backend, Workers
-
Description
Imagine a default Jenkins setup consisting of a single master instance ... a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files.
This does not feel right, considering this scenario an emphasis could be put on a better security setup consisting of a
- robust backend with REST APIs
- GUI
- jailed workers (chroot, docker container, etc.)
- secured messaging backbone for communication between the core and the workers
IMHO and TBD
I did not find a lot of evidence of this topic so far, it might be quite off track of the current jenkins philosophy compromising a bit of security for usability purposes. However security issues are subject to be discussed in enterprise environments and targeting those might be a viable direction.
Attachments
Activity
Field | Original Value | New Value |
---|---|---|
Description |
Imagine a default Jenkins setup consisting of a single master instance ... a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files. This does not feel right, considering this scenario an emphasis could be put on a better security setup consisting of a * robust backend with REST APIs * GUI * jailed workers (chroot, docker container, etc.) * secured messaging backbone for communication between the core and the workers IMHO and TBD I did not find a lot of evidence of this topic so far, it might be quite off track of the current jenkins philosophy compromising a bit of security for usability purposes. However this issues are subject to be discussed in enterprise environments and targeting those might also be a viable direction. |
Imagine a default Jenkins setup consisting of a single master instance ... a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files. This does not feel right, considering this scenario an emphasis could be put on a better security setup consisting of a * robust backend with REST APIs * GUI * jailed workers (chroot, docker container, etc.) * secured messaging backbone for communication between the core and the workers IMHO and TBD I did not find a lot of evidence of this topic so far, it might be quite off track of the current jenkins philosophy compromising a bit of security for usability purposes. However security issues are subject to be discussed in enterprise environments and targeting those might be a viable direction. |
Assignee | Kohsuke Kawaguchi [ kohsuke ] |
Assignee | Kohsuke Kawaguchi [ kohsuke ] |
Resolution | Incomplete [ 4 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Labels | 2.0 | 2.0-declined |
Epic Child | JENKINS-32572 [ 167715 ] |
Labels | 2.0-declined | 2.0-rejected |
Epic Child |
|
Epic Child | JENKINS-35274 [ 170978 ] |
Workflow | JNJira [ 167027 ] | JNJira + In-Review [ 198097 ] |
Epic Child | JENKINS-37606 [ 173724 ] |
Epic Child | JENKINS-32572 [ 167715 ] |
Epic Child |
|
Epic Child | JENKINS-60025 [ 202850 ] |
Epic Child | JENKINS-61013 [ 204483 ] |
Epic Child | JENKINS-61289 [ 204865 ] |
Epic Child | JENKINS-62810 [ 207029 ] |
Epic Child | JENKINS-65731 [ 211471 ] |
Epic Child | JENKINS-65773 [ 211530 ] |
Epic Child | EVENTS-64 [ 215609 ] |