Job-Dsl scanning in Seed Job

[Samantha Oyen]

Hello all –

 

I am one of the Jenkins admins at General Mills, and we are looking into using job-dsl plugin so that developers that use our Jenkins instance can define their jobs in code, check the job-dsl files in to their project, and a seed job will pick up those files and auto create/delete their Jenkins jobs.

 

TL;DR; We want to contribute back to the job-dsl plugin with a feature that allows scanning of the job-dsl code, and the ability to fail the Process Job DSLs step if a job-dsl method that is not in a whitelist is found, or a method that is on the Mandatory list is not found.

Proposal

We would like to contribute back to the job-dsl plugin with a feature that will allow Jenkins administrators to have some control over what is allowed in the job-dsl. Our idea is to for sure have a whitelist of steps, and possibly also a list of mandatory steps (we are defining reusable job-dsl blocks such as fxCopScan(), vs2015BuildStep(), artifactoryConfig(), checkmarxScanning(), etc. to encapsulate some of the complexity since there’s so much similarity between job definitions for our developers – screen shot of what I mean at the bottom of the email), and due to security we need to make sure that a subset of those are executed on every build. Since you already have job-dsl parsing built into your plugin, we thought that would be the most appropriate place to put it. Also, then others in the community that have these same needs could benefit. (these would all be options features of course)

 

The option added to scan job-dsl files in the Process Job DSLs step in the Job Config UI would look something like this:

 

Job-Dsl Scanning – checkbox to opt in. If checkbox is marked, the below options will appear.

-          Whitelist (define steps that are allowed within the job dsl – if any jobs that are not in this whitelist are found the Process Job DSLs step will be failed)

-          Mandatory Steps (list of steps that are mandatory – if any jobs defined in the job-dsls being processed do not contain these steps, the Project Job DSLs step will be failed)

*For both Whitelist and Mandatory, values could be specified in the UI, at a specific filepath, or using a dropdown to select a config file that’s globally configured (much like the Console Parsing plugin)

 

Our Administration Strategy Background

We are switching to this from templates because the templates we have are so locked down (we only have 2 job templates that work out of the box for 90% of developers; and they are only able to edit 4 text field parameters for these template implementations). When they want updates, beyond the parameters they can control, it’s a huge hassle for us. We want developers to be able to modify/tweak their job definitions themselves if our base job doesn’t work for some reason.

The one thing, however, that we need is the ability to somewhat restrict the things that they are adding to their jobs. We’ve looked into a few options, but the one that we have landed on is to have a whitelist and mandatory steps list of job-dsl methods that are allowed; defined somewhere in Jenkins, and to scan the job-dsl files before their processed to ensure that there’s nothing harmful/stupid in them.

(so in implementation, users wouldn’t have access to modify seed or created freestyle jobs, except through the job-dsl file in their project)

 

Is this change something that the community would be interested in for the job-dsl plugin?

[Samantha Oyen]

Also... here is the job-dsl that I referenced above. 

[Victor Martinez]

Have you considered to extend https://github.com/CodeNarc/CodeNarc with your specific rules and check those before processing those job DSL? I believe you could easily use https://github.com/sheehan/job-dsl-gradle-example with https://docs.gradle.org/current/userguide/codenarc_plugin.html to reuse your codenac rules

Cheers

[Samantha Oyen]

Great suggestion! I'll look into hooking into that within the plugin code.

[Daniel Spilker]

Using CodeNarc is a great idea since it would allow to check the rules before commit.

There is also a Jenkins plugin for detecting configuration issues: https://wiki.jenkins-ci.org/display/JENKINS/JenkinsLint+Plugin

Victor, isn't that your plugin? Maybe that plugin can be extended to be invoke as build step to run after "Process Job DSLs" to report any violations.

Daniel

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugin+unsubscribe@googlegroups.com.
To post to this group, send email to job-dsl-plugin@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/3db160d4-4fd9-4217-b236-58f0bfa0ce69%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Samantha Oyen]

So I guess my use case is actually kind of weird. We would actually have to run it during the build process in Jenkins because we're a .NET shop, and we don't want our developers to have to set up a java/groovy environment on their local machine, just because that's the language we're using for job specification on Jenkins.

Also, ideally we would want the Process Job-Dsl step to actually fail if the scanning "failed" (we're basically using this to make sure developers aren't checking in potentially dangerous job definitions that could do bad things to our wonderful build agents/servers.)

That plugin looks awesome, but is a little more global I think than what we're looking for. Also not as configurable as we would need, since we would have to specify a custom Whitelist and Manadatory Build Steps list for what kind of jobs that specific seed job is allowed to create. What we want is a build step before the Process Job-Dsl step (or a part of the Job-dsl plugin) that does that check for a specific seed job, and doesn't create the job from that job-dsl if it finds issues.

I wonder... does this seem like a use case that other Jenkins Administrators that use seed jobs to allow their developers to specify job configurations in code would be interested in?

To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.

[Victor Martinez]

Indeed, that's something I didn't think about so.. I'll see how i can add that feature. Good point

Cheers

To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.

[Samantha Oyen]

Thanks for the response Victor. 

I've already downloaded the plugin, gotten it to debug on my local machine, and have started digging through the code to figure out where I can hook in to fail the job dsl if there's a step that is not allowed by our whitelist. I'm having a bit of a hard time figuring out where to do this. I have at least a few more days to allocate to working on this. Do you think I could chat with you on a google hangouts call for some direction? I totally understand if you're not available, but I'm pretty close to resigning myself to writing a .NET console app to do the parsing and not have it as part of the plugin.

Alternatively, if this is something that you want to take up, definitely go for it. Just let me know if you would be available to chat with me for direction on where to start in the code, if I should resign to creating a .NET console app to do the parsing, or if you have the bandwidth to tackle this yourself.

Thanks so much for your responsiveness Victor!

[Victor Martinez]

Hi Samantha, 

Unfortunately, I don't have enough time to code/implement any new functionality. I wish I could. 

Thanks

[Samantha Oyen]

So I completed my first attempt at adding this feature, and have created a pull request with my changes. Can be found here - https://github.com/jenkinsci/job-dsl-plugin/pull/968

I have added some comments there and would love your guys' thoughts/feedback on the feature.

[Samantha Oyen]

I have completed all unit tests, code, and UI changes for the now pretty much complete Job Dsl Whitelisting feature. 

My strategy changed slightly. Basically there are two ways to whitelist. 1) You can whitelist external classes that are allowed to define blocks of dsl. 2) You can also whitelist what's directly in the script to be processed (doesn't look at any dsl blocks imported from other classes), by specifying the xml parents that are allowed to be generated. 

You can also do a combination of the two. In our use case what we'll be doing is using the 1st whitelisting option to whitelist a helper class which has most of our build dsl blocks in it (defined by our central build and deploy team), and then we will use the 2nd whitelisting option to whitelist some publishing elements that we want our developers to mess with to their heart's content (we use the second whitelisting option for this because developers will be defining this directly in the job-dsl.groovy file that they will be checking into source control).

Any thoughts on this new strategy? Am I missing any use cases?

Again - the pull request that has all the changes is still located at https://github.com/jenkinsci/job-dsl-plugin/pull/968

Thanks!