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

Any way to restrict build for non-whitelisted users?

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In Github Pull Request Builder plugin, It is possible to create whitelist for which PR build automatically. For non whitelisted users admin must  approve that PR to be build. Then comment can trigger build for that PR. Unfortunately it isn't compatible with Pipeline.

      So it will be nice to have those functionality on github-branch-source-plugin. 

        Attachments

          Issue Links

            Activity

            Hide
            stephenconnolly Stephen Connolly added a comment -

            This requires the concept of interesting branches and revisions to be introduced to the SCM API plugin.

            Once that is present then you should be able to mark commits from non-whitelisted users as non-interesting and hence the branch-api plugin suppress automatic building of those commits

            In the interim, the best workaround you can use is to leverage trust for non-origin forks. Builds from non-trusted users will build using the Jenkinsfile from the target branch. Then in your target branch Jenkinsfile you can have the very first thing be a check against the whitelist of users and abort the build if the user is not in the whitelist (you'd probably like to have JENKINS-27092 to allow you to do this with the error step so you could get the natural NOT_BUILT status... but it's not critical if you just need to ensure that the whitelist is enforced)

            Show
            stephenconnolly Stephen Connolly added a comment - This requires the concept of interesting branches and revisions to be introduced to the SCM API plugin. Once that is present then you should be able to mark commits from non-whitelisted users as non-interesting and hence the branch-api plugin suppress automatic building of those commits In the interim, the best workaround you can use is to leverage trust for non-origin forks. Builds from non-trusted users will build using the Jenkinsfile from the target branch. Then in your target branch Jenkinsfile you can have the very first thing be a check against the whitelist of users and abort the build if the user is not in the whitelist (you'd probably like to have  JENKINS-27092 to allow you to do this with the  error  step so you could get the natural  NOT_BUILT  status... but it's not critical if you just need to ensure that the whitelist is enforced)
            Hide
            brianjmurrell Brian J Murrell added a comment -

            The proposed solution doesn't really implement what the OP is requesting.

            He doesn't want to outright refuse to build PRs from non-whitelisted users but wants them to be sent to an approval queue where he can release them to be built or reject them.

            This kind of security is really quite important as without it, it allows all-comers to execute any code they want on your builders.

            Show
            brianjmurrell Brian J Murrell added a comment - The proposed solution doesn't really implement what the OP is requesting. He doesn't want to outright refuse to build PRs from non-whitelisted users but wants them to be sent to an approval queue where he can release them to be built or reject them. This kind of security is really quite important as without it, it allows all-comers to execute any code they want on your builders.
            Hide
            jgray599 Jonathan Gray added a comment -

            100% agree.  The GHPRB plugin which appears to have now been deprecated in favor of github-branch-source-plugin has a major feature gap that appears to have been misunderstood here.  This is a blocker issue for us on migrating away from GHPRB, and from a security perspective we're currently in a less than desirable position since GHPRB seems to presently have security issues.

             

            As a maintainer of an OSS project running a self-hosted Jenkins instance for the community, I want to build all PRs by those who are trusted contributors (which may be more than just those with merge rights) automatically.  For those who are not trusted, the PR build needs to be authorized via PR comment by a trusted user before it is built.  This should support Multibranch pipeline style jobs via Jenkinsfile so that the build process itself may be updated by untrusted OSS contributors.  This approval pipeline/step/check is critical because you must protect against malicious PR modifications of a Jenkinsfile.

            Show
            jgray599 Jonathan Gray added a comment - 100% agree.  The GHPRB plugin which appears to have now been deprecated in favor of github-branch-source-plugin has a major feature gap that appears to have been misunderstood here.  This is a blocker issue for us on migrating away from GHPRB, and from a security perspective we're currently in a less than desirable position since GHPRB seems to presently have security issues.   As a maintainer of an OSS project running a self-hosted Jenkins instance for the community, I want to build all PRs by those who are trusted contributors (which may be more than just those with merge rights) automatically.  For those who are not trusted, the PR build needs to be authorized via PR comment by a trusted user before it is built.  This should support Multibranch pipeline style jobs via Jenkinsfile so that the build process itself may be updated by untrusted OSS contributors.  This approval pipeline/step/check is critical because you must protect against malicious PR modifications of a Jenkinsfile.
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

            Show
            stephenconnolly Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA
            Hide
            brianjmurrell Brian J Murrell added a comment -

            Stephen Connolly Your workaround suggestion in the first comment along with Jenkinsfile's input step could lead to a more useful workaround.

            The only thing that is missing is the ability for a Jenkinsfile to determine the "trust"ability of the PR.  Is that at all possible?

            Show
            brianjmurrell Brian J Murrell added a comment - Stephen Connolly Your workaround suggestion in the first comment along with Jenkinsfile 's input step could lead to a more useful workaround. The only thing that is missing is the ability for a Jenkinsfile to determine the "trust"ability of the PR.  Is that at all possible?
            Hide
            jgray599 Jonathan Gray added a comment -

            It's also a human interfacing issue too.  Once the concept of trust apart from committership/ownership exists, the existing solution uses the PR itself as the CI interface to permit/retry/whitelist the build/submitter.

            Show
            jgray599 Jonathan Gray added a comment - It's also a human interfacing issue too.  Once the concept of trust apart from committership/ownership exists, the existing solution uses the PR itself as the CI interface to permit/retry/whitelist the build/submitter.

              People

              • Assignee:
                Unassigned
                Reporter:
                ashiquzzaman33 Ashiquzzaman Ashiq
              • Votes:
                4 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: