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

Non-user-scoped credentials are not shown when build authentication is configured

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • credentials-plugin
    • None
    • Credentials Plugin 2.2.1

      Tested with:
      Jenkins 2.176.2
      Authorize Project 1.3.0
      Matrix Authorization Strategy Plugin 2.4.2
      Git 3.11.0

      Only user-scoped credentials are displayed in job configuration pages when the job is configured to authenticate as a specific user.
      But non-user-scoped credentials also should be displayed when the user has the Credentials/View permission.

      This behavior is inconsistent with the behavior that users with Credentials/View permissions can see non-user-scoped credentials in the credentials page. This is confusing for many users.

      Steps to reproduce:

      1. Launch Jenkins
      2. Install following plugins:
        • Credentials Plugin 2.2.1
        • Authorize Project 1.3.0
        • Matrix Authorization Strategy Plugin 2.4.2
        • Git 3.11.0
      3. Create following users
        • admin
          • All permissions
        • user1
          • All permissions except Overall/Administer
      4. Configure Access Control for Builds:
        1. Go to Manage Jenkins > Configure Global Security
        2. Add "Per-project configurable Build Authorization" in Access Control for Builds
        3. check "Run as Specific User"
      5. Add following credentials:
        • nonuserscoped1
          • Credentials > Jenkins > Global credentials (unrestricted) > Add Credentials
          • Configure as following:
            • Kind: Username with password
            • Scope: Global (Jenkins, nodes, items, all child items, etc)
            • Username: nonuserscoped1
            • Password: nonuserscoped1
            • ID: nonuserscoped1
        • userscoped1
          • Login as users1
          • user1 (by clicking the username in the right up)> Credentials > User: user1 >
          • Configure as following:
            • Kind: Username with password
            • Username: userscoped1
            • Password: userscoped1
            • ID: userscoped1
      6. Login as user1 and open user1 > Credentials page.
        • nonuserscoped1 and userscoped1 are displayed. This means users can expect both nonuserscoped1 and userscoped1 are available for user1.
      7. Login as user1 and create a free style project "test1" and select "Git" for "Source Code Management"
        • "nonuserscoped1" is listed in "Credentials".
        • "userscoped1" is not listed in "Credentials".
      8. Open "Authorization" of test1, check "Configure Build Authorization" and configure as followings:
        • Authorize Strategy: Run as Specific User
        • User ID: user1
        • Don't restrict job configuration: leave unchecked
      9. Open "Configure" of test1 and see "Credentials" in "Git"
        • "nonuserscoped1" is not listed in "Credentials".
          • Even though it is listed in user1 > Credentials page. This must be unexpected for many users.
        • "userscoped1" is listed in "Credentials".

      This is caused for SystemCredentialsProvider provides credentials only to SYSTEM user.
      https://github.com/jenkinsci/credentials-plugin/blob/credentials-2.2.1/src/main/java/com/cloudbees/plugins/credentials/SystemCredentialsProvider.java#L446

      Git plugin looks request credentials for authentication of the job correctly, and this looks an issue of credentials plugin:
      https://github.com/jenkinsci/git-plugin/blob/git-3.11.0/src/main/java/hudson/plugins/git/UserRemoteConfig.java#L103

          [JENKINS-58902] Non-user-scoped credentials are not shown when build authentication is configured

          ikedam created issue -
          ikedam made changes -
          Link New: This issue is duplicated by JENKINS-55624 [ JENKINS-55624 ]
          ikedam made changes -
          Link New: This issue is duplicated by JENKINS-38126 [ JENKINS-38126 ]
          ethorsa made changes -
          Link New: This issue relates to JENKINS-59973 [ JENKINS-59973 ]
          Ben Faucher made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]

          Ben Faucher added a comment -

          I am also seeing this. This is a significant problem; until it is fixed I have to set "Project default build authorization" to run as the SYSTEM user, which is a security hole.

          Ben Faucher added a comment - I am also seeing this. This is a significant problem; until it is fixed I have to set "Project default build authorization" to run as the SYSTEM user, which is a security hole.

          Larry Cai added a comment -

          any progress or plan for this bug?

          Larry Cai added a comment - any progress or plan for this bug?

          faucherb94 at least in our cases, it has turned out to be enough to change the "Project default build authorization" to SYSTEM for the short period where you pick the credentials in the job. Once the job is saved with the correct credentials, we can set the setting back, and the job will still run and use the correct credentials. It does give a warning from this point on in the job configuration page, where it complain that it cannot find the chosen credentials, but as long as you do not change that part (leave it on current) it is possible to make changes to the job.

           

          Still irretating, but a lot better safer than keeping running jobs as SYSTEM.

          Anders Kreinøe added a comment - faucherb94 at least in our cases, it has turned out to be enough to change the "Project default build authorization" to SYSTEM for the short period where you pick the credentials in the job. Once the job is saved with the correct credentials, we can set the setting back, and the job will still run and use the correct credentials. It does give a warning from this point on in the job configuration page, where it complain that it cannot find the chosen credentials, but as long as you do not change that part (leave it on current) it is possible to make changes to the job.   Still irretating, but a lot better safer than keeping running jobs as SYSTEM.

          Nikolas Falco added a comment -

          We get this issue since long time and now debugging to resolve it and looking for exising bug I land here.

          This issue happens when I configure projects FreeStyle. We are not able to setup any credentials.
          We configure authorisation project using "Project default Build Authorisation" with "Run As Specific user" valued with the technical user we use for the build (same issue with an administrator account).

          Also read this documentation with attention there is a note that say:

          If you install the Authorize Project plugin and configure a job to run as a specific user, the credentials available to that job will now be determined by that user’s permissions in the context of that job. If the user does not have either Credentials/UseOwn (normally implied by Item/Build) or Credentials/UseItem (normally implied by Job/Configure) then the job will be unable to access any credentials at all.

          .
          As it is implemented any provider should take care about ACL.SYSTEM and CredentialsProvider.USE_OWN and of CredentialsProvider.USE_ITEM to get ACL of selected user and all credentials for which it has visibility.
          Indeed as ikedam reported 2 years ago the SystemCredentialProvider does not contribute with global credentials also if current user can see tham and this prevent to create any kind of FreeStyleJob with a SCM (git in our case). For sure SystemCredentialProvider is not the only point where I saw this logic (if (ACL.SYSTEM.equals(authorisation))).
          At runtime it perform a totally different trip using CredentialsProvider.findCredentialById that takes in consideration the use case of CredentialsProvider.USE_OWN and CredentialsProvider.USE_ITEM.

          Nikolas Falco added a comment - We get this issue since long time and now debugging to resolve it and looking for exising bug I land here. This issue happens when I configure projects FreeStyle. We are not able to setup any credentials. We configure authorisation project using "Project default Build Authorisation" with "Run As Specific user" valued with the technical user we use for the build (same issue with an administrator account). Also read this documentation with attention there is a note that say: If you install the Authorize Project plugin and configure a job to run as a specific user, the credentials available to that job will now be determined by that user’s permissions in the context of that job. If the user does not have either Credentials/UseOwn (normally implied by Item/Build) or Credentials/UseItem (normally implied by Job/Configure) then the job will be unable to access any credentials at all. . As it is implemented any provider should take care about ACL.SYSTEM and CredentialsProvider.USE_OWN and of CredentialsProvider.USE_ITEM to get ACL of selected user and all credentials for which it has visibility. Indeed as ikedam reported 2 years ago the SystemCredentialProvider does not contribute with global credentials also if current user can see tham and this prevent to create any kind of FreeStyleJob with a SCM (git in our case). For sure SystemCredentialProvider is not the only point where I saw this logic ( if (ACL.SYSTEM.equals(authorisation)) ). At runtime it perform a totally different trip using CredentialsProvider.findCredentialById that takes in consideration the use case of CredentialsProvider.USE_OWN and CredentialsProvider.USE_ITEM.
          Nikolas Falco made changes -
          Remote Link New: This issue links to "PR (Web Link)" [ 27354 ]

            Unassigned Unassigned
            ikedam ikedam
            Votes:
            20 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: