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.
- 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.
- 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.
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.
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.
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.
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):
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.