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

Do not run a Multibranch Pipeline job if Jenkinsfile is updated by unauthorized people

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Context
      We have more than 300 Pipeline jobs to run Maven builds (CI, Sonar...) into Docker containers for 50+ GitHub projects.
      All those pipeline jobs are generated, thanks to the Job DSL plugin:

      pipelineJob(){
          ...
          definition {
              cps {
                script('''#!groovy
      node('ci-docker'){
          exoCI{}
      }
      ''' + "${upstreamJob}")
              }
            }
      }
      

      It's ok for some CI & Sonar jobs (develop/master/stable branches) but not useful to automatically build PRs and so on.

      Why do we not use Jenkinsfiles on our GitHub projects?

      We do not use the Jenkinsfile on our git projects for now because we can't control "who is able to do what" on those specific files.
      Indeed, even we can manage people who have write access to our GitHub repositories, we do not consider those Jenkinsfiles like others Java, XML... code source files.

      We applied the recommended practices by disabling executors on the master and by having CI servers agents with "only" Docker & Git installed, but despite this we don't want that "unauthorized people" can execute whatever commands on those servers by using the Jenkinsfile.

      Proposition

      My proposition to fix this problem is to manage a whitelisted users (and whitelisted organisation for GitHub) to identify which people are able to execute a build with an updated Jenkinsfile in the SCM.

      • if the Jenkinsfile is the same as the default branch -> execute the build
      • if the Jenkinsfile has been updated by people in the whitelisted users -> execute the build
      • otherwise do not execute the build

      WDYT?

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          I am not following.

          if the Jenkinsfile is the same as the default branch -> execute the build

          So, anyone who has write permission on that repository can change the Jenkinsfile in the default branch at any time and do what they want. Having a whitelist of users would not help.

          If you do not want people with push permission to write arbitrary Pipeline script, then you may not use WorkflowBranchProjectFactory (the by Jenkinsfile option in the UI). CloudBees Jenkins Platform includes a more locked-down version; others could use the same extension point. Or you may use non-multibranch projects, as you are doing.

          If you even suspect a security flaw in the current code. when used as designed as documented, do not file it here. Use the security issue tracker.

          Show
          jglick Jesse Glick added a comment - I am not following. if the Jenkinsfile is the same as the default branch -> execute the build So, anyone who has write permission on that repository can change the Jenkinsfile in the default branch at any time and do what they want. Having a whitelist of users would not help. If you do not want people with push permission to write arbitrary Pipeline script, then you may not use WorkflowBranchProjectFactory (the by Jenkinsfile option in the UI). CloudBees Jenkins Platform includes a more locked-down version; others could use the same extension point. Or you may use non-multibranch projects, as you are doing. If you even suspect a security flaw in the current code. when used as designed as documented, do not file it here. Use the security issue tracker.
          Hide
          mgreau Maxime GREAU added a comment - - edited


          So, anyone who has write permission on that repository can change the Jenkinsfile in the default branch at any time and do what they want. Having a whitelist of users would not help.

          I forgot to explain that I use the new "Restrict who can push to this branch" GitHub feature here, so that I can control who can push to the default branch (whitelist users) and who can push to others branches.

          If you even suspect a security flaw in the current code. when used as designed as documented, do not file it here. Use the security issue tracker.

          Ok, sorry, I removed security label/component.

          CloudBees Jenkins Platform includes a more locked-down version

          I will take a look, thanks.

          Or you may use non-multibranch projects, as you are doing.

          Ok, in that case what's the better way to automatically generate jobs by listening to webhooks?

          Thanks

          Show
          mgreau Maxime GREAU added a comment - - edited So, anyone who has write permission on that repository can change the Jenkinsfile in the default branch at any time and do what they want. Having a whitelist of users would not help. I forgot to explain that I use the new "Restrict who can push to this branch" GitHub feature here, so that I can control who can push to the default branch (whitelist users) and who can push to others branches. If you even suspect a security flaw in the current code. when used as designed as documented, do not file it here. Use the security issue tracker. Ok, sorry, I removed security label/component. CloudBees Jenkins Platform includes a more locked-down version I will take a look, thanks. Or you may use non-multibranch projects, as you are doing. Ok, in that case what's the better way to automatically generate jobs by listening to webhooks? Thanks
          Hide
          jglick Jesse Glick added a comment -

          what's the better way to automatically generate jobs by listening to webhooks?

          See JENKINS-37220.

          Show
          jglick Jesse Glick added a comment - what's the better way to automatically generate jobs by listening to webhooks? See JENKINS-37220 .

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            mgreau Maxime GREAU
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: