Reputation: 3539
I am trying to implement the following user journey with Jenkins:
This serves two purposes: the SSH key stored on the build host is protected and it also prevents accidental triggering of the "deploy" operation which is otherwise indistinguishable from any other Jenkins job. It does not appear that I can configure an SSH private key as a Jenkins credential without the passphrase and only provide it at job execution time. The Jenkins instance runs on Linux.
How would you implement this? One possible solution is to use pre-/post-build shell scripts to start a new ssh-agent as part of the Jenkins job execution, and load the key into that, then stop it after the deployment is completed. It seems like there should be a more elegant way to do this though.
Upvotes: 1
Views: 1869
Reputation: 2254
The elegant way is to have Dev and Operations Jenkins systems and use the Build publish plugin to publish from one to the other. Only allow Operations access to the Production jenkins system to run jobs from.
Separate out Building and Deploying into separate jobs, not tasks. You can then link the jobs together, even across jenkins servers using a combination of Build Publish and Pipeline plugin.
This allows us to have very very strict access controls on our Prod jenkins, and our Dev Jenkins remains the "wild west" without ticking off Dev teams.
I can answer your question directly if you like, but auditing production builds amongst hundreds of dev/qa/uat pushes is a nightmare.
Upvotes: 1