CODEWITHSUNDEEP
githubjenkinsjenkins-plugins
Maciek
Maciek

Reputation: 516

Externalizing passwords from Jenkins job

I have a Jenkins job where I pull code from github using Git plugin. Due to networking limitations the only way I can do it is by making https calls with username and password as part of the git project url

https://${username}:${passsword}@github.com/${project}.git

${project} is being parameterized on job level but ${username} and ${password} is currently hardcoded in the url. I would like to externalize it somehow to some kind of global config. I tried several ways like global properties, system env etc. but none worked. Neither ${username} nor ${password} is being replaced by Jenkins. The only working way (so far - for me) is to make it a job parameter but I wanted to make it global for all my jobs.

Any ideas? Thanks!

Upvotes: 0

Views: 2844

Answers (3)

Florian
Florian

Reputation: 544

You can use the Jenkins Credentials plugin to store user name and password credentials. When configuring your job, choose the credentials in the Git configuration. The repository URL will not include username and password anymore. AFAIK this requires an up-to-date Jenkins installation with latest Git and Git Client plugins.

I managed to get this working with a Git HTTP URL that used a fixed repository path. So far I failed with providing the repository as a variable as you seem to be doing.

Note that the current Git client plugin version 1.4.6 does not respect your no proxy hosts setting if you have a proxy configured in Jenkins. A patch is available here: https://github.com/fzs/git-client-plugin/tree/respect-no_proxy

Upvotes: 2

andy-berry-dev
andy-berry-dev

Reputation: 2324

Similar to djangofan's answer:

The best way to do this is use SSH keys. Generate an SSH public/private key and then put the private key on each of the Jenkins slaves in ~/.ssh/config. You then add the public key to your GitHub account profile. GitHub has a page on this - https://help.github.com/articles/generating-ssh-keys#platform-all

Better still, use deploy keys. Its basically the same as above, but instead of adding the SSH public key to a user account, you add it to a repo's deploy keys - https://help.github.com/articles/managing-deploy-keys#deploy-keys

Once you have this all setup instead of using https://${username}:${passsword}@github.com/${project}.git you use the SSH URL to clone, [email protected]:${project}.git

I would also avoid using the same SSH keypair on every slave and on dev machines. Use separate keypairs as deploy keys so you can then revoke them individually if one is compromised. Devs are also then responsible for generating their own keypairs and adding them to their account (not as a deploy key).

If you want to stay on the HTTPS route here is a good post for removing the username/password from the URL. From experience I have found SSH deploy keys easier to manage in a CI environment.

Upvotes: 0

djangofan
djangofan

Reputation: 29669

IDEA #1 :

What I usually do at my work is that we use a public/private key pair. I don't totally understand how it works completely but, when I do a Git clone from either my workstation OR if Jenkins does a Git clone, it doesn't need a password since the auth cert handles it. Therefore, Git commands in scripts, including Jenkins "git plugin" clones, all work without password.

Upvotes: 0

Related Questions