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
kisa
added a comment - I'm aware of the plugins ... and the major architectural change 
just thought about pushing the best practices into the core
kisa
added a comment - I'm aware of the plugins ... and the major architectural change just thought about pushing the best practices into the core Assigning something to KK will not get him to look at it.
Also,
a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files.
See https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices and scroll down to the last item. See https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins and scroll down to the last section. Building on slaves and not building on master has long been a best practice, but cannot really be done 'out of the box'.
* jailed workers (chroot, docker container, etc.)
Look into cloud slave plugins, e.g. Docker or vSphere Cloud. They essentially allocate a new slave for every build.
As to the rest, this looks to me like someone who does not seem to be a contributor to Jenkins, and may not even know Jenkins internals (judging from the rest of this request), is suggesting major architectural changes that will definitely break all the plugins. This isn't the best starting point for getting something going, it's difficult enough for long time contributors to initiate something like this.
Back your ideas with proof that it's actually feasible, otherwise this is will lead nowhere. Nobody will bother to disprove the feasibility of wild, unproven ideas.
Right, but it's impossibly to determine right now whether you know what you're writing about or are just another crackpot. Ideally you'd be an established contributor that earned some trust, or have a prototype going.
FWIW there are plans to tackle the storage backend (https://wiki.jenkins-ci.org/display/JENKINS/Storage+Backend+Changes), and towards Jenkins 2.0 we're working on a more client JS/server JSON API based UI including infra support for plugins to make use of that. I doubt we'll ever be able to get rid of the traditional Stapler approach due to backward compatibility concerns though.