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

Pipeline-as-Code CredentialsProvider for a job

      There should be an analogue of FolderCredentialsProvider limited to a single Job, allowing credentials to be set on the narrowest possible scope.

      Not Workflow specific, but arguably more important for flows since they are likely to replace a whole set of freestyle projects that might otherwise have been segregated into a distinct folder.

          [JENKINS-27398] Pipeline-as-Code CredentialsProvider for a job

          Jesse Glick created issue -

          Feel free to implement this in a plugin

          Stephen Connolly added a comment - Feel free to implement this in a plugin
          Stephen Connolly made changes -
          Assignee Original: Stephen Connolly [ stephenconnolly ] New: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-27386 [ JENKINS-27386 ]

          Jesse Glick added a comment -

          An idea inspired by a conversation with kohsuke:

          A new Pipeline Step which is able to define certain kinds of IdCredentials, probably limited to UsernamePasswordCredentialsImpl and StringCredentialsImpl to start with (but could be an extension point to add other options). The configuration would be similar to the credentials configuration view, except that Secret-valued fields would be data-bound specially: the secret would be salted with the job name (or a folder prefix—so that you could use Snippetizer from a WorkflowMultiBranchProject or OrganizationFolder), encrypted against InstanceIdentity.public¹, and the result Base64-encoded. When run, the text would be Base64-decoded, decrypted against InstanceIdentity.private, the salt stripped off and verified (must be the job name or a folder prefix thereof), the resulting Secret used to create the desired IdCredentials, and this would be cached² in a special CredentialsProvider keeping a per-job list. So then usage would look like (pending JENKINS-29922):

          credentials [$class: 'UsernamePassword', id: 'hipchat-login', username: 'bob', password: 'abc/def+GHI0123=']
          hipchat server: …, message: …, credentialsId: 'hipchat-login'
          

          ¹Or perhaps a subclass of RSAConfidentialKey is the more modern way to do this? RSADigitalSignatureConfidentialKey does not look appropriate.

          ²The credentials must be persisted to disk somehow, to support builds running across Jenkins restarts, though they could be deleted when the Run finishes. The CredentialsProvider API provides no way to limit the credentials to a single Run of the Job, which could lead to surprises if you change the secret and are running concurrent builds: an earlier build might wind up picking up a secret edited in a later build. I think this is an acceptable limitation. There should not be a security risk for pull request builds since (a) credentials are set per job and thus per branch/PR; (b) an origin Jenkinsfile could simply decline to run the step if running in a PR. Merely seeing the encrypted text in the Jenkinsfile does not let you recover the secret without knowing the instance’s private key, nor could you use it in another job because of the salt.

          Jesse Glick added a comment - An idea inspired by a conversation with kohsuke : A new Pipeline Step which is able to define certain kinds of IdCredentials , probably limited to UsernamePasswordCredentialsImpl and StringCredentialsImpl to start with (but could be an extension point to add other options). The configuration would be similar to the credentials configuration view, except that Secret -valued fields would be data-bound specially: the secret would be salted with the job name (or a folder prefix—so that you could use Snippetizer from a WorkflowMultiBranchProject or OrganizationFolder ), encrypted against InstanceIdentity.public ¹, and the result Base64-encoded. When run, the text would be Base64-decoded, decrypted against InstanceIdentity.private , the salt stripped off and verified (must be the job name or a folder prefix thereof), the resulting Secret used to create the desired IdCredentials , and this would be cached² in a special CredentialsProvider keeping a per-job list. So then usage would look like (pending JENKINS-29922 ): credentials [$class: 'UsernamePassword' , id: 'hipchat-login' , username: 'bob' , password: 'abc/def+GHI0123=' ] hipchat server: …, message: …, credentialsId: 'hipchat-login' ¹Or perhaps a subclass of RSAConfidentialKey is the more modern way to do this? RSADigitalSignatureConfidentialKey does not look appropriate. ²The credentials must be persisted to disk somehow, to support builds running across Jenkins restarts, though they could be deleted when the Run finishes. The CredentialsProvider API provides no way to limit the credentials to a single Run of the Job , which could lead to surprises if you change the secret and are running concurrent builds: an earlier build might wind up picking up a secret edited in a later build. I think this is an acceptable limitation. There should not be a security risk for pull request builds since (a) credentials are set per job and thus per branch/PR; (b) an origin Jenkinsfile could simply decline to run the step if running in a PR. Merely seeing the encrypted text in the Jenkinsfile does not let you recover the secret without knowing the instance’s private key, nor could you use it in another job because of the salt.
          Jesse Glick made changes -
          Epic Link New: JENKINS-35386 [ 171179 ]

          Yes that is an interesting idea.

          Stephen Connolly added a comment - Yes that is an interesting idea.
          Jesse Glick made changes -
          Component/s New: workflow-plugin [ 18820 ]
          Component/s Original: credentials-plugin [ 16523 ]
          Labels Original: workflow New: credentials
          Summary Original: CredentialsProvider based on JobProperty New: Pipeline-as-Code CredentialsProvider for a job
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 161603 ] New: JNJira + In-Review [ 180761 ]
          Andrew Bayer made changes -
          Component/s New: pipeline-general [ 21692 ]

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: