get secret from master based on user/password auth

[Constantin07]

This PR is to address the issue in jenkinsci/docker-agent#701 .

It's doesn't break existing functionality (use of only JENKINS_SECRET).

[oleg-nenashev]

Thanks for the pull request @Constantin07 ! It would be a nice improvement. It will not work as is, because CRUMB is hardcoded. E.g. see https://support.cloudbees.com/hc/en-us/articles/219257077-CSRF-Protection-Explained which explains how to get it

I would also suggest using JENKINS_API_TOKEN as a variable name to encourage people to use it instead of the password. CC @Wadeck

[oleg-nenashev]

Wdyt about renaming JENKINS_PASSWORD to JENKINS_API_TOKEN ?

[Constantin07]

@oleg-nenashev done.

Tested locally - slave successfully connects to master using username/password.

jenkins-slave    | Warning: JnlpProtocol3 is disabled by default, use JNLP_PROTOCOL_OPTS to alter the behavior
jenkins-slave    | Jan 07, 2019 10:19:11 AM hudson.remoting.jnlp.Main createEngine
jenkins-slave    | INFO: Setting up agent: jenkins-slave
jenkins-slave    | Jan 07, 2019 10:19:11 AM hudson.remoting.jnlp.Main$CuiListener <init>
jenkins-slave    | INFO: Jenkins agent is running in headless mode.
jenkins-slave    | Jan 07, 2019 10:19:11 AM hudson.remoting.Engine startEngine
jenkins-slave    | INFO: Using Remoting version: 3.27
jenkins-slave    | Jan 07, 2019 10:19:11 AM hudson.remoting.Engine startEngine
jenkins-slave    | WARNING: No Working Directory. Using the legacy JAR Cache location: /root/.jenkins/cache/jars
jenkins-slave    | Jan 07, 2019 10:19:12 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Locating server among [http://jenkins_master:8080]
jenkins-slave    | Jan 07, 2019 10:19:12 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
jenkins-slave    | INFO: Remoting server accepts the following protocols: [JNLP4-connect, Ping]
jenkins-slave    | Jan 07, 2019 10:19:12 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Agent discovery successful
jenkins-slave    |   Agent address: jenkins_master
jenkins-slave    |   Agent port:    50000
jenkins-slave    |   Identity:      bf:27:e3:8d:fb:89:a5:6d:19:1e:67:b0:92:5f:f5:11
jenkins-slave    | Jan 07, 2019 10:19:12 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Handshaking
jenkins-slave    | Jan 07, 2019 10:19:12 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Connecting to jenkins_master:50000
jenkins-slave    | Jan 07, 2019 10:19:12 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Trying protocol: JNLP4-connect
jenkins-slave    | Jan 07, 2019 10:19:13 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Remote identity confirmed: bf:27:e3:8d:fb:89:a5:6d:19:1e:67:b0:92:5f:f5:11
jenkins-slave    | Jan 07, 2019 10:19:15 AM hudson.remoting.jnlp.Main$CuiListener status
jenkins-slave    | INFO: Connected

[syndbg]

@Constantin07 Great work!

@oleg-nenashev It would be great if this gets merged and published in DockerHub.

[jglick]

This seems like a bad idea. You are replacing a limited token good only for connecting this agent with a general personal access token which, if compromised, could be abused in various ways. What exactly is the use case here?

[dduportal]

I'm closing this PR for the following reasons:

• Even if the fix is well explained, the use case is not clearly defined (what is the problem do you want to solve?)
• This PR did not receive an answers since years
• There are code conflicts: the PR uses a really old and outdated code.

Of course, feel free to reopen it if you feel it should be reviewed and merged (but you'll have to describe the initial problem and solve the merge conflicts).

[jglick]

The use case I can think of is that you are configuring the controller via JCasC including a static agent, and wish to be able to reconstruct the setup from scratch (with a freshly generated $JENKINS_HOME/secrets/ directory). But then I think you would still need to use custom scripting, at least pending jenkinsci/configuration-as-code-plugin#1830, in which case you may as well script the retrieval of the agent HMAC as well.

The better solution would be to deprecate the agent HMAC generally. Instead each newly created agent would get a randomly generated connection token persisted as a (Secret) field in the agent definition; from JCasC you could set a specific token value drawn from the usual sources (e.g., Vault). @daniel-beck @Wadeck do you know if this idea is tracked anywhere?

[Wadeck]

=> https://issues.jenkins.io/browse/JENKINS-70168 just created
It was discussed inside SECURITY tracker but it should be public.