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?