As this article states this is "current best-practices" maybe then some effort should be made to kill the bugs of the credential bind plugin that makes the best practice insecure. See https://issues.jenkins-ci.org/browse/JENKINS-24805 open for 2 years. Due to this the plugin is disabled in our company, leading to yet more hack workarounds that sap our time. Please fix!
The issue https://issues.jenkins-ci.org/browse/JENKINS-24805 seems to be solved, and credentials are now masked on the console output of a job log. However, a simple "echo $MY_SECRET > secret.txt" shows the secret into a text file on the workspace.
I've been trying to use the same thing for my username and password but when I echo, I get **** as the output.
I've followed all of the instructions above and I've created the credentials as global in the credential management page. Is there any mistake im making?
Thanks for the response. However, where can we use these variables then? They're set as env variables but I'm not able to access them. When I say access, forget echo, but if I need to send them along with a curl call, how do I use them? My requirement is to send them via a curl call, the echo was just for testing.
Is there a specific example of using a secret file that needs to be read by a build agent from within a pipeline job? I cannot seem to get that to work.
@Jesse That ("withCredentials") did the trick. The only glitch is that I need to define the secret file on each master rather than just once in the CJOC that is upstream of the masters. That might be a CJOC bug and so I'll ping support.
@Jesse I am trying to access the secret text(which is an auth token) in httprequest as authorization header. I am using withCredentials. However, I am unable to use the variable defined in withCredentials.Any suggestions?
If you are a CloudBees customer feel free to raise a ticket. If not you can use the Community to try and get you question answered, but please provide more details as to what is going wrong.
I have the same problem as Cola Vn, whose question was never answered. I'd like to use the actual values for the username/password instead of "****" but there is no information that I can find on how to do this.
Same problem as Cola Vn. If I do the following my authentication fails, and I have no way of knowing what value is being passed to the script because of the masking.
Protip : you can't echo out your username/password variables because they're always obscured, but you can cat them out. This helped me trace where my script chain was losing their values.
Tip: if you are debugging a problem in your script and you are sure no one else can see this build log and you will plan to delete the build record as soon as you are done, it is possible to transform the output in such a way that it is still human-readable but does not literally contain the secrets. For example:
sh 'echo sshpass -p $PASSWORD scp -r $USERNAME@example.com:/path/to file.txt | od -a'
Hari: in the context of this article, as long as the command that you intend to run has a way to supply credentials non-interactively you should be able to inject the secrets as explained here.
Comments
30 comments
Is it possible to inject credentials when invoking Ant in Jenkins?
re: Ant,
It possible to load a properties file from an ant script; in theory you could load a secret file.
Note: I am not using this yet from Jenkins ... because I am browsing this thread to learn how!
As this article states this is "current best-practices" maybe then some effort should be made to kill the bugs of the credential bind plugin that makes the best practice insecure. See https://issues.jenkins-ci.org/browse/JENKINS-24805 open for 2 years. Due to this the plugin is disabled in our company, leading to yet more hack workarounds that sap our time. Please fix!
Totally agree with Paul.
The issue https://issues.jenkins-ci.org/browse/JENKINS-24805 seems to be solved, and credentials are now masked on the console output of a job log. However, a simple "echo $MY_SECRET > secret.txt" shows the secret into a text file on the workspace.
Please fix !
Jj Cm: as designed. Masking only exists to reduce the chance of accidental disclosure.
Hi!
I've been trying to use the same thing for my username and password but when I echo, I get **** as the output.
I've followed all of the instructions above and I've created the credentials as global in the credential management page. Is there any mistake im making?
Much thanks! :D
Hi Cola,
Like said Jesse this is as designed. We are masking them in the console to reduce the chance of accidental disclosure.
Best regards
Hi Arnaud,
Thanks for the response. However, where can we use these variables then? They're set as env variables but I'm not able to access them. When I say access, forget echo, but if I need to send them along with a curl call, how do I use them? My requirement is to send them via a curl call, the echo was just for testing.
Rgds
Hi Jesse & Arnaud,
I have the same problem as Cola. How do I use my secret text in a CURL request?
Currently all I get is the ID of the secret, but not the secret itself...
@Manuel I am not sure how that could happen. If you are a CloudBees customer, please file a support request.
Is there a specific example of using a secret file that needs to be read by a build agent from within a pipeline job? I cannot seem to get that to work.
@Mark yes there is a Secret file example above.
@Jesse Is the "Secret File" example above the same for both a FreeStyle job as well as a Pipeline job?
For a Pipeline job, you would need to use the withCredentials step; see the Pipeline Syntax link for details.
@Jesse That ("withCredentials") did the trick. The only glitch is that I need to define the secret file on each master rather than just once in the CJOC that is upstream of the masters. That might be a CJOC bug and so I'll ping support.
Thanks for your help.
@Mark yes a support ticket would be appropriate. This sounds like a known bug CJP-7068, for which a fix may be coming soon.
@Jesse I am trying to access the secret text(which is an auth token) in httprequest as authorization header. I am using withCredentials. However, I am unable to use the variable defined in withCredentials.Any suggestions?
Hi Chaitanya,
If you are a CloudBees customer feel free to raise a ticket. If not you can use the Community to try and get you question answered, but please provide more details as to what is going wrong.
Secret Text drop down value unavailable under the Kind option while adding Global Credentials in Jenkins v 1.570. Any clue on how to enable that??
Thanks in advance
Hi, Dashit,
Secret Text is provided by the Plain Credentials plugin. You need to check if it is installed.
Also, we highly recommend you upgrade your Jenkins. 1.570 is a three-year-old weekly release.
Hello,
I have the same problem as Cola Vn, whose question was never answered. I'd like to use the actual values for the username/password instead of "****" but there is no information that I can find on how to do this.
Thanks!
Same problem as Cola Vn. If I do the following my authentication fails, and I have no way of knowing what value is being passed to the script because of the masking.
stage('Deploy') {
steps {
withCredentials([usernamePassword(credentialsId: 'myUploader', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
sh 'sshpass -p $PASSWORD scp -r $USERNAME@example.com:/path/to file.txt'
}
}
}
If I try to pass password or username to a test variable and deliberately console them out, all I get are masked characters :
test="--${USERNAME}--${PASSWORD}" && echo $test
I get
Masking variables is all good and well, but how are we supposed to pass these variables to scripts if they contain literally masked characters?
Protip : you can't echo out your username/password variables because they're always obscured, but you can cat them out. This helped me trace where my script chain was losing their values.
Tip: if you are debugging a problem in your script and you are sure no one else can see this build log and you will plan to delete the build record as soon as you are done, it is possible to transform the output in such a way that it is still human-readable but does not literally contain the secrets. For example:
Is there a way to prevent passwords from being displayed using the methods that Shukuri Adams and Jesse Glick listed?
@Chris: no. https://github.com/jenkinsci/credentials-binding-plugin/blob/1c2ca93a80e47f1662b160b809d4bf8876a58995/src/main/resources/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep/help.html
i wanted to login to remote machine without entering username and password as i wanted to supply creds from jenkins..
is it possible?
Hari: in the context of this article, as long as the command that you intend to run has a way to supply credentials non-interactively you should be able to inject the secrets as explained here.
Possibly newer content: https://docs.cloudbees.com/docs/cloudbees-ci/latest/cloud-secure-guide/injecting-secrets
Please sign in to leave a comment.