I'd like to manage Jenkins 2 configuration by puppet.
I've copied configuration from deployed manually instance, and templated it.
But I've got problem with hashed passwords in configuration. When I'm putting old hash (from previous instance) jenkins is overwritting it, and password does not work. For example:
<managerDN><%= scope['ldap_bind_dn'] %></managerDN>
<managerPasswordSecret><%= scope['ldap_bind_pw'] %></managerPasswordSecret>
I've got BIND password and dn stored in hiera, and when I'm putting it from hiera and restart Jenkins, config is rewritten and new value does not work.
- <managerPasswordSecret>{HASH_FROM_HIERA=}</managerPasswordSecret>
+ <managerPasswordSecret>{NEW_NOT_WORKING_HASH=}</managerPasswordSecret>
I cannot figure out how to manage this credentials in a way Jenkins will accept them?
I've found solution, just instead of hash, puppet should place plain-text and jenkins automatically will replace it with proper hash value
Related
I have a problem. I use Jenkins to deploy application on machines. Depending on which machine i want to deploy new version I need to use different database passwords to run db migrations. I want to store credentials in Jenkins and for each deploy job select credentials set from dropdown which will be passed (just password ) to powershell script. I have Credentials Binding Plugin and Extended Choice Parameter Plugin. I thought it might help me with my problem, but I cannot find solution for this. Do you have any ideas how to achieve this?
As I understand, you need only to do two things:
add Credential Parameter in This project is parameterized section for possibility to select credentials set from dropdown.
enable Use secret text(s) or file(s) option in Build Environment section. This will allow you to take credentials of various sorts and use them from shell build steps and the like. Each binding will define an environment variable.
If you have already created Jenkins credentials like these:
then you will be available to run your job using Build with Parameters button and select needed credentials:
So, after configuring, you don't need to dig in job configuration each time, all possible credentials will be automatically loaded, you need only select the needed one when run a job.
I've tried a variety of solutions and I can't find something that works. My problem is that I want to be able to put a deployment key (what GitHub calls a personal authorization token or personal OAuth token) into an encrypted variable in my Travis settings for the repository so that the configuration file never has to change. For example, I'd like to do this:
deploy:
api_key:
secure: $DEPLOYMENT_KEY
I could now checkin code that doesn't need to be changed in order to be deployed. If multiple people were to fork my repository, they could simply add their own Travis variable and not touch the code at all.
However, I've been unsuccessful in getting this to work. What sequence would accomplish this, if it's possible at all?
Solution
I accepted the answer below that put me on the right track, although the actual text that I needed in my configuration file wasn't shown. I've put it here:
deploy:
api_key: $DEPLOYMENT_KEY
I had a "eureka!" moment and realized that any subway of 'secure:' could be replaced with an actual unencrypted value, which is what Travis inserts when you substitute an encrypted variable. (It does the decryption and puts the result into the variable, which is then substituted into the api_key by the dollar sign.)
You cannot write:
deploy:
api_key:
secure: $DEPLOYMENT_KEY
Decryption happens in an early stage of Travis CI build processing; the encrypted value will be passed on to the app which compiles the bash script to build. Since the part that is responsible for decrypting secrets doesn't know anything about $DEPLOYMENT_KEY, this configuration will fail.
To achieve what you are after, you can use the repository settings to define secrets. See https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings.
Thus, I understand that:
either, you put an awful long encrypted key in your .travis.yml
or, you put an unencrypted key in a Travis environment variable, so that if any developer of the GitHub project can add in .travis.yml something like:
echo "${API_TOKEN:0:1}%POISON%${API_TOKEN:1}"
he can get your private API_TOKEN secret by reading travis logs (even if your variable is not set as DISPLAY VALUE IN BUILD LOG since this hack disrupts the usual [secure] replacement in logs)
Reminder: since GitHub API_TOKEN is not restricted by repository, that bad guy can do anything with all your repositories (write access and read access to your private repo).
NB: I found this blog post with a more safe solution (but not perfect) which requires an external server to serve temporary API_TOKEN.
Is there any other solution ?
My aim:
To use a password in jenkins which is masked after input and runtime.
I only need it for my job.
I can use it in my java code to login to a website.
Areas I have looked at:
The credentials plugin - this looks like the right area (but I'll need to get the sysadmins to add me as its locked down).
Also I can't find out how you can access the output?
Have a look into the EnvInject plugin, there you can define password parameters that are masked in console output and job configuration, they can be used like normal parameters.
The screenshot shows the configuration in the job to use a local password.
The shell script build step I used is
echo "myPassword = $myPassword"
The resulting console output is:
+ echo 'myPassword = [*******]'
myPassword = [*******]
To pass it to Java you can use it like any other parameter from the job configuration. The value itself is encrypted, so checking the job configuration as XML will not reveal the password either.
You can use the jenkins credentials binding plugin.
After installing the Credentials Bindings plugin, the Build Environment section of your build job Configuration page will include a new option:
Use secret text(s) or file(s)
Enabling this option allows you add credential bindings where the Variable value will be used as the name of the environment variable that your build can use to access the value of the credential.
See the full description of all steps here:
https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
I want to verify and validate credentials (user and password) by using Credentials-plugin for Jenkins. I added Credentials-plugin in my POM file. But I don't know how to verify access to my domain name.
Do you have any idea how I can verify credentials for a domain name (aa.example.com) by using credentials-plugin through java.
Thanks
Jenkins 'credential' plugin is to facilitate keeping passwords(user/pwd or any other form) safe outside of code. So you can only use those wherever you want in code by using the variable names you have created in configuration. Jenkins will get this password to you wherever you ask but it will not use those for any authentication. It is up to us to get the values through system vairables and use them to authenticate for given domain name. Refer below to see if that is helping you.
Inject passwords to the build as environment variables
I have about 20 jobs using common parameters (user, password), and sometimes the password expires... So I have to change it on all jobs, which is really time consuming (and error prone, I may forget one).
I thought about:
using a kind of magic property file if that exists to have directly lines like KEY, VALUE added into job parameters
adding the same kind of KEY, VALUE pair directly inside build.xml, but where ? And it's really ugly... Maybe with a dedicated XML embedded into the build.xml ?
calling a slave job that would (how ?) push up to the parent one the desired values...
As you can see I'm only starting in Hudson/Jenkins (I'm using Jenkins 1.424.2.2), thanks for your help !
EDIT: I'm not admin of the Jenkins instance, so I cannot have access to global properties...
Go to your Jenkins home and navigate :
Manage Jenkins >
Configure System >
Global properties >
Environment variables > ....
I can think of two approaches:
Use Global properties, found under Manage Jenkins -> Configure system. Here you can define environment variables that should be available to all jobs.
Write a small script that downloads, modifies and posts the job config: http://[jenkinshost]/job/[jobname]/config.xml.
You can read about the api capabilities under http://[jenkinshost]/job/[jobname]/api, here is what it says about reading and changing config.xml:
Fetch/Update config.xml
To programmatically obtain config.xml, hit
[http://[jenkinshost]/job/[jobname]/config.xml]. You can also POST
an updated config.xml to the same URL to programmatically update the
configuration of a job.
I eventually succeeded by:
keeping encrypted credentials in a web page
retrieving them in Hudson thanks to a shell script (wget), decrypt them, and creating a build.properties file in the workspace with lines name=value (in my case ssh.password=...)
This works, because Ant build steps detect this file and pass the variables inside into their context. Thanks to that I could centralize my credentials.