Stephen Connolly added a comment - 2016-05-20 21:26 Feel free to implement this in a plugin

Jesse Glick added a comment - 2016-06-11 09:49 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.

Stephen Connolly added a comment - 2016-06-11 10:09 Yes that is an interesting idea.