Best Practices for Setting up Jenkins Auditing and Compliance

Many Jenkins users look for a recommend a strategy for keeping an audit trail. This article is supposed to be a gap filler until more comprehensive compliance capabilities in JE/JOC are developed.

There are two open source plugins that enable you to track “WHO did WHAT?” in Jenkins: 
  • Audit Trail Plugin: adds an “Audit Trail” section in your Jenkins main configuration page, where it is possible to define where to save logs on who performed particular operations on Jenkins.

 

Audit Trail - output fileScreen Shot 2015-01-13 at 09.32.28.png
 
  • Job Config History Plugin: stores all the changes made to jobs (history), saving the config.xml of each job. For each change, it is possible to see the record of the change, compare the difference between the new and the old version and restore a previous version. It is also possible to keep track of the changes made to the system configuration.
 
Job Config History - compare differences GUI option
Screen Shot 2015-01-13 at 09.24.30.png

 

Although the Job Config History plugin looks somewhat more complete, this, differently from the Audit Trail Plugin, does not track any information regarding the job execution and the exit status.

 

Audit Trail - executions of jobs

 

For this reason, many users use both The Audit Trail plugin and the Job Config History plugins to track both the changes and the executions of jobs.
 

Packages Traceability

For artifacts and packages, Jenkins keep track of those using the fingerprint. However, when they go outside Jenkins, there is no way to track them. Lately Jenkins has become more and more a tool for continuous delivery (CD), and integrating with automation tools is essentials. For this reason, CloudBees has partnered with vendors who offer popular tools, like Chef and Puppet, to enhance Jenkins traceability.

Thanks to the Deployment Notification Plugin applicable to Chef and Puppet, it is possible to keep track of the artifact even when it leaves the jenkins environment to be deployed on a remote server. The information maintained by Jenkins for each deployed package are the date/time, the hostname of the remote server, the environment and the deployment path.
 

 
Puppet Plugin - traceability
 

Audit when Using the Workflow Plugin

With the new Workflow plugin, it is possible to configure an entire continuous delivery pipeline in a single job with a simple Groovy-based script, rather than using different jobs and several plugins to orchestrate the execution of the “flow.”

While it is possible to directly insert the Groovy code in the box of the workflow-job ad-hoc configuration page, it is recommended to store the workflow script in a repository and just load it from inside the Groovy box.
 

Workflow plugin - loading groovy script from repository
 

In the example above, the workflow script is stored in a local repository, checked out in the building machine, loaded and its functions accessed directly. This guarantees audit and version control since each change made to the script will be committed to the SCM and thus it is possible to keep track of who changed what.
 

This applies to all Configuration As Code approaches (i.e. DSL plugin, Literate plugin).

Audit when Performing Cluster Operations Using Jenkins Operations Center

With the new (December v1.6) release of Jenkins Operations Center by CloudBees, it is possible to perform management operations to all the client masters in one pass:

  • Restart client masters
  • Backup client masters
  • Run Groovy script on client masters
  • Upgrade Jenkins core on client masters
  • Install new plugins on client masters
  • Enable/disable plugins on client masters
  • Upgrade/downgrade plugin on client masters

Jenkins keeps track of these operations treating them as normal jobs and giving each operation a specific place on the file system where to store execution information and logs.

The same are accessible from the Graphical User Interface (GUI):
 

 
Cluster Operations - logs in GUI
If authentication is enabled, information on “WHO did WHAT and WHERE” is visible here.

Although at the moment there is not a unique and satisfying way to implement audit trail, the options presented above, combined together, should give a good coverage to all the activities performed on Jenkins.

 
Valentina Armenise
Software Engineer
CloudBees
 

Comments

Great Stuff!

Hi, the article is very insteresting but not solve my problem. I need to collect all Login/Logout actions of Jenkins users. How I can collect these in the audit log file? Is It possibe? Thanks a lot. Antonio

Add new comment