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

Authorize Projects plugin causes no git credentials to be found with 'Run as Specific User' Strategy is set

      When attempting to configure source control for a freestyle job with the Build Authorization Strategy set to 'Run as Specific User', I don't see any available git credentials.

      I have credentials installed and they appear when I set Build Authorization Strategy to "Run as User who Triggered Build". See attached images.

      However, if I set the Build Authorization Strategy to "Run as User who Triggered", configure my job with the proper credentials and then switch to "Run as specific user", everything works, but when I go to configure the job the git credentials section of the config page displays the error that the currently configured credentials cannot be found.  This is an ugly workaround but it does let my job run as desired.

      Steps to Reproduce:

      • Install Authorize Project
      • Configure Global Security > Access Control for Builds and to allow Per-project configurable build authorization with the "Run as Specific User" and "Run as User who Triggered Build" strategies. 
      • Add another user to the local Jenkins user database.
      • Create a new freestyle project. 
      • Enable git source control and add some credentials and select those.  Save the project.
      • Enable "Configure Build Authorization" and set the strategy to "Run as Specific User". Set this to the new user you added (in my case this was not the same as my currently logged in user but testing showed that it didn't make a difference what user I entered)
      • Go back to the Configure page for the job.  Observe that no credentials can be found according to the error on the Git SCM section of the page and no credentials appear in the drop down menu.
      • Switch the projects authorization strategy to "Run as user who Triggered Build"
      • Go back to the Configuration page for the job. Observe that the credentials appear valid and all available credentials appear.

          [JENKINS-55624] Authorize Projects plugin causes no git credentials to be found with 'Run as Specific User' Strategy is set

          ikedam added a comment -

          That looks caused for the newly added user doesn’t have a permission to access that credentials. It sounds an expected behavior.

          Anyway, this is an issue of credentials-plugin and I update the cemponent and the assignee.

          ikedam added a comment - That looks caused for the newly added user doesn’t have a permission to access that credentials. It sounds an expected behavior. Anyway, this is an issue of credentials-plugin and I update the cemponent and the assignee.

          Peter Philipp added a comment -

          Since Jenkins pushed the Build Authorization https://jenkins.io/doc/book/system-administration/security/build-authorization/ with the last update, we didn't want to dismiss this and added the plugin.

          And we also started experiencing the same issue as described in the summary.
          However, it seems like this is actually a git-plugin related issue because while the git plugin doesn't list the parent / global credentials, the docker plugin lists them properly. (I couldn't test if these credentials work yet or are just listed.)
          I've also tried to tune the user permissions but no matter if the specified user has full or just limited permissions the parent credentials wont show up.

          Checking the issue history of the git-plugin it seems like there has been quite a collection related issues e.g.:
          https://issues.jenkins-ci.org/browse/JENKINS-38126?focusedCommentId=289182&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-289182
          https://issues.jenkins-ci.org/browse/JENKINS-44773
          Following issue also links to some other related issues: https://issues.jenkins-ci.org/browse/JENKINS-44774

          Given all that I wonder if the bug report should be filed / merged with one of the git-plugin related issues.

          As for now we switched back to using the SYSTEM user.

           

          Peter Philipp added a comment - Since Jenkins pushed the Build Authorization https://jenkins.io/doc/book/system-administration/security/build-authorization/ with the last update, we didn't want to dismiss this and added the plugin. And we also started experiencing the same issue as described in the summary. However, it seems like this is actually a git-plugin related issue because while the git plugin doesn't list the parent / global credentials, the docker plugin lists them properly. (I couldn't test if these credentials work yet or are just listed.) I've also tried to tune the user permissions but no matter if the specified user has full or just limited permissions the parent credentials wont show up. Checking the issue history of the git-plugin it seems like there has been quite a collection related issues e.g.: https://issues.jenkins-ci.org/browse/JENKINS-38126?focusedCommentId=289182&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-289182 https://issues.jenkins-ci.org/browse/JENKINS-44773 Following issue also links to some other related issues: https://issues.jenkins-ci.org/browse/JENKINS-44774 Given all that I wonder if the bug report should be filed / merged with one of the git-plugin related issues. As for now we switched back to using the SYSTEM user.  

          Nick Jones added a comment - - edited

          I see the same behavior, and it appears to be specific to Freestyle jobs using Git as an SCM; Mercurial and Subversion still present the full list of credentials to choose from. Accordingly, I've added git-plugin to the Component/s list here.

          Also, creating a new user and adding credentials are not necessary as part of reproducing this. It is enough to have an existing Freestyle job that uses an existing "username with password" credential for the Git SCM configuration on the job. Simply switching the global build authorization strategy from "Run as SYSTEM" to "Run as Specific User" (and specifying a user, of course) causes the credentials list when configuring a job to be empty. Jobs that were already created (prior to this switch) will have a "current" option in the list, and will still build (i.e., checkout) properly, but new jobs will only have "none" and thus will fail.

          Nick Jones added a comment - - edited I see the same behavior, and it appears to be specific to Freestyle jobs using Git as an SCM; Mercurial and Subversion still present the full list of credentials to choose from. Accordingly, I've added git-plugin to the Component/s list here. Also, creating a new user and adding credentials are not necessary as part of reproducing this. It is enough to have an existing Freestyle job that uses an existing "username with password" credential for the Git SCM configuration on the job. Simply switching the global build authorization strategy from "Run as SYSTEM" to "Run as Specific User" (and specifying a user, of course) causes the credentials list when configuring a job to be empty. Jobs that were already created (prior to this switch) will have a " current " option in the list, and will still build (i.e., checkout) properly, but new jobs will only have " none " and thus will fail.

          ikedam added a comment -

          There're three underlying issues causing this issue:

          • Why this happens only for "Run as specific user" , not for other strategies like "Run as User who Triggered"?:
            • Because credentials in configuration pages are not for the user of builds, but for the user of the job. Jenkins can say that the user of the job is "user1" when you are using "Run as specific user" with "user1" though Jenkins cannot decide the user of the job when you are using "Run as User who Triggered" as the user can be decided only after a build is actually triggered by someone. So "Run as User who Triggered" results configuration pages behave just as when no authorization strategy is set. And this issue is specific to "Run as specific user".
          • What is credentials for specific users?
            • You can configure user-scoped credentials in the user page, which can open from the link over the user name in the right-up part of Jenkins web UI.
          • Why system global credentials are not displayed in the job configuration pages even when the user has Credentials/View permissions?
            • It might be a bug of credentials plugin (I'm not so sure as I don't know much about the design of credentials-plugin). I created JENKINS-58902 and please watch that ticket.

          ikedam added a comment - There're three underlying issues causing this issue: Why this happens only for "Run as specific user" , not for other strategies like "Run as User who Triggered"?: Because credentials in configuration pages are not for the user of builds, but for the user of the job. Jenkins can say that the user of the job is "user1" when you are using "Run as specific user" with "user1" though Jenkins cannot decide the user of the job when you are using "Run as User who Triggered" as the user can be decided only after a build is actually triggered by someone. So "Run as User who Triggered" results configuration pages behave just as when no authorization strategy is set. And this issue is specific to "Run as specific user". What is credentials for specific users? You can configure user-scoped credentials in the user page, which can open from the link over the user name in the right-up part of Jenkins web UI. Why system global credentials are not displayed in the job configuration pages even when the user has Credentials/View permissions? It might be a bug of credentials plugin (I'm not so sure as I don't know much about the design of credentials-plugin). I created JENKINS-58902 and please watch that ticket.

          iostrym added a comment -

          hello, I have the same problem using git-plugin and authorize project.

          on my side I am in "run as specific user" because, if I'm correct, I cant' use "run as user who triggered" as it will fail if the job is launched automatically each week (user will be system instead of the user).

          I don't undestand if there is a workaround for me without waiting for the correction ?

          my goal also is to have credential that are stored and visible to all but only for the user who created them.

          iostrym added a comment - hello, I have the same problem using git-plugin and authorize project. on my side I am in "run as specific user" because, if I'm correct, I cant' use "run as user who triggered" as it will fail if the job is launched automatically each week (user will be system instead of the user). I don't undestand if there is a workaround for me without waiting for the correction ? my goal also is to have credential that are stored and visible to all but only for the user who created them.

          iostrym added a comment -

          I have a workaround following precedent post :

          "Simply switching the global build authorization strategy from "Run as SYSTEM" to "Run as Specific User" (and specifying a user, of course) causes the credentials list when configuring a job to be empty. Jobs that were already created (prior to this switch) will have a "current" option in the list, and will still build (i.e., checkout) properly,"

           

          But this time another user can use credential created by another user. Is it possible to restrict the visibility of credential created by other users ?

          iostrym added a comment - I have a workaround following precedent post : "Simply switching the global build authorization strategy from "Run as SYSTEM" to "Run as Specific User" (and specifying a user, of course) causes the credentials list when configuring a job to be empty. Jobs that were already created (prior to this switch) will have a " current " option in the list, and will still build (i.e., checkout) properly,"   But this time another user can use credential created by another user. Is it possible to restrict the visibility of credential created by other users ?

          iostrym added a comment -

          hello, the workaround can't be deployed because for this I need to autorize user to temporary switch authorization strategy to "run as system" and this way they can launch their job on any node and that is not secure at all.

          Then what would be the solution to have this working without waiting for the bug correction ?

          iostrym added a comment - hello, the workaround can't be deployed because for this I need to autorize user to temporary switch authorization strategy to "run as system" and this way they can launch their job on any node and that is not secure at all. Then what would be the solution to have this working without waiting for the bug correction ?

            mikenicholson Mike Nicholson
            mikenicholson Mike Nicholson
            Votes:
            5 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: