3

I'm working with Jenkins servers in three different environments:Development-Staging-Production.

We work out the kinks in our Jenkins jobs in dev, test them in stage, and then finally move them to production. We do that be either replicating the job in the GUI (cut and paste) or tarring up the job directory and moving it to the next environment via the command line.

I'm wondering if the move option can be done with the service accounts that run these jobs. I can see the user account directories and config files under /var/lib/jenkins/users. What I don't see are the security settings that get applied to the user from the "Configure Global Security" screen in the GUI.

For these service accounts, we have the minimal authorization of READ on Global and READ and BUILD on Jobs.

What I'd like to be able to do is prove a service account in dev and then promote it to Stage and Prod from the command line vs having to manually recreate the account in the GUI for each upstream environment. If the API key could also be moved along with it that would be great.

Any thoughts or ideas?

Michael J
  • 1,383
  • 2
  • 14
  • 25

2 Answers2

1

User permissions are in config.xml under the Jenkins root folder, in section <authorizationStrategy>

This file contains other global settings, so just copying it would not be advisable

Slav
  • 27,057
  • 11
  • 80
  • 104
  • 1
    Yes, I figured that would be the case. What I'm asking for is a slick way to extract the settings and permissions for a single account and then insert them into another Jenkins install; an "Export/Import User" plugin perhaps? Looking at the config.xml, I guess i could grep out the permissions for the account and then sed them into the next config.xml after copying over the account directory. – Michael J Mar 20 '14 at 18:29
  • 1
    A "slick" way would be to authorize users against the AD, have AD groups configured with permissions in Jenkins, and you would never have to manage individual users through Jenkins again, just manage their group membership in AD ;) – Slav Mar 20 '14 at 18:32
  • @MichaelJ An alternative to AD is OpenLDAP. Most tools have some form of LDAP support. It works even better when you map access roles to LDAP groups. – Mark O'Connor Mar 20 '14 at 21:47
  • I do see the wisdom behind AD and LDAP -- options we could use -- but I guess I can be more specific in the accounts I'm talking about. These are just service accounts. That is, we have other tools that make calls to Jenkins after deployments, updates, etc to do restarts and/or other deployments. So no user logs into these accounts. So when we set the user & job up in dev, then prove it, I'd like to quickly move it to stage for the same...then prod...etc. I will update my question to reflect this. Just the same, thanks for the comments! – Michael J Mar 21 '14 at 20:59
0

Just a wild thought, but why not use a master-slave config and trigger builds on the desired remote machine based on some "environment" parameter. You can also look through the plugins section to see if you can find something useful such as the:

  • node label parameter which allows to define and select the label for the node where you want the build to run
  • copy to slave that facilitates copying files to and from a slave

That way you'll only have one job configuration which can be executed on different environments without too much hustle.

Morfic
  • 15,178
  • 3
  • 51
  • 61
  • We use a similar "hub and spoke" method for our code repository; one repo that writes to dev, stg, and prod. However, our Jenkins environment dosen't lend itself to this type of set up given the three distinct Jenkins installs. – Michael J Jul 23 '15 at 23:37