Details
-
Type:
Improvement
-
Status: Resolved (View Workflow)
-
Priority:
Minor
-
Resolution: Won't Fix
-
Component/s: core
-
Environment:Oracle Enterprise Linux/Redhat 6.x
-
Similar Issues:
Description
A slave node in a secured Jenkins environment requires jnlpCredentials in order to connect to Jenkins. These credentials are supplied via the -jnlpcredentials command-line argument to the java command, but that easily exposes them to others.
For example:
java -jar slave.jar -jnlpCredentials user:pass -jnlpUrl http://somewhere/xx.jnlp
Please provide an alternate parameter for the option that allows the slave credentials to be supplied in a file that is read during slave start-up. Alternately, you could select a file name (e.g. .jslaverc) that would be checked for credentials if you didn't want to introduce a new command-line parameter for slave.jar startup. Either way would get the credentials off of the command-line, making them less accessible to other users of the system.
Attachments
Activity
The -secret option is definitely a viable option to the proposed work-around. At the time that this was originally written, the -secret syntax wasn't clearly documented and we didn't have a way to determine the secret value for a node programatically from a script. I have since figured out how to query the secret value for a node using a groovy script.
for (aSlave in hudson.model.Hudson.instance.slaves) {
println aSlave.name + "," + aSlave.getComputer().getJnlpMac()
}
Scott Moomaw
added a comment - The -secret option is definitely a viable option to the proposed work-around. At the time that this was originally written, the -secret syntax wasn't clearly documented and we didn't have a way to determine the secret value for a node programatically from a script. I have since figured out how to query the secret value for a node using a groovy script.
for (aSlave in hudson.model.Hudson.instance.slaves) {
println aSlave.name + "," + aSlave.getComputer().getJnlpMac()
} The correct -secret argument line is produced automatically when you get the actual JNLP from Jenkins.
Can we at least try to support environment variables for these parameters? It's ridiculous that you can see secrets from the process name.
smek
added a comment - Can we at least try to support environment variables for these parameters? It's ridiculous that you can see secrets from the process name. The capability is already there, it's just not well documented.
It's built into the command-line processing library the Remoting agent library uses.
If a command-line argument begins with a '@' (at symbol), then the rest of that argument is interpreted as the path to a file. Each line in the file is inserted as a command-line argument.
Using the `-secret` parameter, you would create a file with a single line containing the secret key. Then reference it in the command-line something like this: "java -jar agent.jar -jnlpUrl -secret @</path/to/secret/file>".
You could also create a four line file something like this:
-jnlpUrl
http://somewhere/xx.jnlp
-secret
<SECRET>
and then invoke it like this: "java -jar agent.jar @</path/to/arguments/file>"
It would be nice to assemble some better documentation on this if someone gets a chance. I've got a note to do it if I can get the time.
Jeff Thompson
added a comment - - edited The capability is already there, it's just not well documented.
It's built into the command-line processing library the Remoting agent library uses.
If a command-line argument begins with a '@' (at symbol), then the rest of that argument is interpreted as the path to a file. Each line in the file is inserted as a command-line argument.
Using the `-secret` parameter, you would create a file with a single line containing the secret key. Then reference it in the command-line something like this: "java -jar agent.jar -jnlpUrl -secret @</path/to/secret/file>".
You could also create a four line file something like this:
-jnlpUrl
http://somewhere/xx.jnlp
-secret
<SECRET>
and then invoke it like this: "java -jar agent.jar @</path/to/arguments/file>"
It would be nice to assemble some better documentation on this if someone gets a chance. I've got a note to do it if I can get the time. It works. Thank you.
You actually see from jenkins ui that you have to run it in a full command line. It's probably better that the example command there gets replaced. People would just run it blindly following the example.
smek
added a comment - It works. Thank you.
You actually see from jenkins ui that you have to run it in a full command line. It's probably better that the example command there gets replaced. People would just run it blindly following the example. Hii Jeff Thompson is there a documentation that describe how to pass secret from a file?? Tnx a lot
Documentation is here: https://github.com/jenkinsci/remoting/blob/master/docs/inbound-agent.md#the--argument-annotation . Someday we need to get this into a more central location.
Jeff Thompson
added a comment - Documentation is here: https://github.com/jenkinsci/remoting/blob/master/docs/inbound-agent.md#the--argument-annotation . Someday we need to get this into a more central location. 
Is this still an issue with the -secret argument method of authentication, e.g.
java -jar slave.jar -jnlpUrl http://jenkins/computer/slavename/slave-agent.jnlp -secret 39689ae1d7e114c806f45c0287f95717647ab1f4c7555c7e1778d4cfc623a964It's available at least since 1.509.x. You cannot do anything except launch a slave (different from real user credentials), and only while it's not already connected, and it gets logged on the master.