Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-31599

Split Jenkins GUI, Jenkins Backend, Jenkins Workers

    Details

    • Epic Name:
      2.0 Security, Split GUI, Backend, Workers
    • Similar Issues:

      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

          Hide
          danielbeck Daniel Beck added a comment -

          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.

          Show
          danielbeck Daniel Beck added a comment - 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.
          Hide
          kisa 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

          Show
          kisa 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
          Hide
          danielbeck Daniel Beck added a comment -

          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.

          Show
          danielbeck Daniel Beck added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              kisa kisa
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: