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

User-scoped credentials cannot be looked up in pipeline

      It's possible to look-up User-scoped credentials in Freestyle jobs with Bindings. The same seems not to work in pipeline jobs.

      node {
          withCredentials([[$class          : 'UsernamePasswordMultiBinding', credentialsId: 'bc047678-37b8-4747-95d8-c1a8b3df51a6',
                            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
              echo "${env.USERNAME}"
          }
      }
      
      org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: bc047678-37b8-4747-95d8-c1a8b3df51a6
      	at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:124)
      	at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.bind(UsernamePasswordMultiBinding.java:68)
      	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution.start(BindingStep.java:92)
      

      Plugin versions:
      credentials-binding: 1.9
      credentials: 2.1.5

          [JENKINS-38963] User-scoped credentials cannot be looked up in pipeline

          Jesse Glick added a comment -

          stephenconnolly knows more about user-scoped credentials. Possibly you need to use Authorized Project to associate an authentication with the build. There is no test case in this plugin that covers user-scoped credentials so as far as I am concerned it is not supported.

          Jesse Glick added a comment - stephenconnolly knows more about user-scoped credentials. Possibly you need to use Authorized Project to associate an authentication with the build. There is no test case in this plugin that covers user-scoped credentials so as far as I am concerned it is not supported.

          So to fetch user scoped credentials there are one of two conditions that must be met, either:

          1. The build must be running as the user that owns the credentials (this requires the AuthorizedProject plugin be configured); or
          2. The credentials must come from a credentials parameter and be selected by the user and that user must have the Credentials/USE_OWN permission (typically implied by Job/BUILD unless you request them separated out by setting a system property). If you use the default credentials in the parameter, then those will not be searched for as the idea is to prevent the user's credentials being hijacked without an explicit selection by the user triggering the build

          Stephen Connolly added a comment - So to fetch user scoped credentials there are one of two conditions that must be met, either: 1. The build must be running as the user that owns the credentials (this requires the AuthorizedProject plugin be configured); or 2. The credentials must come from a credentials parameter and be selected by the user and that user must have the Credentials/USE_OWN permission (typically implied by Job/BUILD unless you request them separated out by setting a system property). If you use the default credentials in the parameter, then those will not be searched for as the idea is to prevent the user's credentials being hijacked without an explicit selection by the user triggering the build

          Clint Chapman added a comment -

          I've tried #2 where I have admin priviledges setup in the global security using matrix based security and am selecting the credential in a parameter - but when I run the job, I still get:
          org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: cchapman
          at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:153)

          Clint Chapman added a comment - I've tried #2 where I have admin priviledges setup in the global security using matrix based security and am selecting the credential in a parameter - but when I run the job, I still get: org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: cchapman at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:153)

          We are seeing a similar issue. I tried using #1 with AuthorizedProject and running as the user's own credentials, but it cannot look up credentials in the Global scope of that user anyway.

          I also tried #2 where the credentials are selected by the user, but still get a CredentialNotFound.

          Using credentials-binding:1.11, authorize-project:1.3.0, credentials:2.1.13.

          Closest workaround right now that seems to work is to use the Folders plugin to apply credentials at the folder level rather than the user level, but it's not ideal.

          Aaron Davidson added a comment - We are seeing a similar issue. I tried using #1 with AuthorizedProject and running as the user's own credentials, but it cannot look up credentials in the Global scope of that user anyway. I also tried #2 where the credentials are selected by the user, but still get a CredentialNotFound. Using credentials-binding:1.11, authorize-project:1.3.0, credentials:2.1.13. Closest workaround right now that seems to work is to use the Folders plugin to apply credentials at the folder level rather than the user level, but it's not ideal.

          Benjamin Cohen Solal added a comment - - edited

          I've created a job with the following lines on pipeline :

          sshagent(['7349b914-da60-441e-b847-1ede672b6bbe']) {
              // some block
          }

          The above credentials are scoped inside my user.

          When activating the "run as user who triggered build" option, I have the following error :

          17:53:27 FATAL: [ssh-agent] Could not find specified credentials

          But when activating the "run as specific user" and specifying my own username, I get the following line :

          17:52:51 [ssh-agent] Using credentials bcohen (My SSH private key)

          I really don't understand why the options "Run as specific user: bcohen" and "Run as user who triggered build" produce a different result when in these two cases, I'm the user who trigger the build.

          Using credentials-binding:1.12, authorize-project:1.3.0, credentials:2.1.14.

          Benjamin Cohen Solal added a comment - - edited I've created a job with the following lines on pipeline : sshagent([ '7349b914-da60-441e-b847-1ede672b6bbe' ]) { // some block } The above credentials are scoped inside my user. When activating the "run as user who triggered build" option, I have the following error : 17:53:27 FATAL: [ssh-agent] Could not find specified credentials But when activating the "run as specific user" and specifying my own username, I get the following line : 17:52:51 [ssh-agent] Using credentials bcohen (My SSH private key) I really don't understand why the options "Run as specific user: bcohen" and "Run as user who triggered build" produce a different result when in these two cases, I'm the user who trigger the build. Using credentials-binding:1.12, authorize-project:1.3.0, credentials:2.1.14.

          Ben Dean added a comment -

          stephenconnolly's method #2 does seem to work for me. Here's an example pipeline.

          properties([
              parameters([
                  credentials(name: 'creds_param', credentialType: 'org.jenkinsci.plugins.plaincredentials.impl.StringCredentialsImpl', required: true)
              ])
          ])
          
          
          stage('example'){
              node {
                  withCredentials([string(credentialsId: '${creds_param}', variable: 'SECRET')]) {
                      sh 'echo $SECRET'
                  }
              }
          }
          

          Note that the single quotes around '${creds_param}' is not a mistake. The CredentialsProvider.findCredentalById method specifically looks to see if the id starts with ${ and ends with }. See https://github.com/jenkinsci/credentials-plugin/blob/master/src/main/java/com/cloudbees/plugins/credentials/CredentialsProvider.java#L882

          This makes it so user creds selected as build params work in the withCredentials pipeline step. That's not really enough for my problems because I want to use parameters from an input step, but that's maybe a different issue. Thought I'd share this.

          Ben Dean added a comment - stephenconnolly 's method #2 does seem to work for me. Here's an example pipeline. properties([ parameters([ credentials(name: 'creds_param' , credentialType: 'org.jenkinsci.plugins.plaincredentials.impl.StringCredentialsImpl' , required: true ) ]) ]) stage( 'example' ){ node { withCredentials([string(credentialsId: '${creds_param}' , variable: 'SECRET' )]) { sh 'echo $SECRET' } } } Note that the single quotes around '${creds_param}' is not a mistake. The CredentialsProvider.findCredentalById method specifically looks to see if the id starts with ${ and ends with } . See https://github.com/jenkinsci/credentials-plugin/blob/master/src/main/java/com/cloudbees/plugins/credentials/CredentialsProvider.java#L882 This makes it so user creds selected as build params work in the withCredentials pipeline step. That's not really enough for my problems because I want to use parameters from an input step, but that's maybe a different issue. Thought I'd share this.

          Jesse Glick added a comment -

          Well that is surprising, to say the least. Would need to be emphasized in inline help for the credentials parameter type.

          Jesse Glick added a comment - Well that is surprising, to say the least. Would need to be emphasized in inline help for the credentials parameter type.

          Matt Sicker added a comment -

          This feature is improved in JENKINS-58170 and will also be supported by an upcoming release of pipeline-input-step to support user-scoped credentials prompted via an input step.

          Matt Sicker added a comment - This feature is improved in JENKINS-58170 and will also be supported by an upcoming release of pipeline-input-step to support user-scoped credentials prompted via an input step.

          Matt Sicker added a comment -

          This was implemented in JENKINS-58170, though it requires the use of credentials build parameters. Alternatively, you can use authorize-project to automate the user who is bound to the build to access their credentials.

          Matt Sicker added a comment - This was implemented in JENKINS-58170 , though it requires the use of credentials build parameters. Alternatively, you can use authorize-project to automate the user who is bound to the build to access their credentials.

          Vít Zikmund added a comment - - edited

          Hello there, jvz. If you suggest using the authorize-project plugin for this purpose, can you confirm it actually works? All my white-box attempts so far failed as those in JENKINS-44772.

          Vít Zikmund added a comment - - edited Hello there, jvz . If you suggest using the authorize-project plugin for this purpose, can you confirm it actually works? All my white-box attempts so far failed as those in JENKINS-44772 .

            Unassigned Unassigned
            vehovmar Martin Vehovsky
            Votes:
            28 Vote for this issue
            Watchers:
            34 Start watching this issue

              Created:
              Updated:
              Resolved: