casc reload groovy command breaks jobdsl plugin if executed by pipeline step load()

Your checklist for this issue

• Jenkins version: 2.190.3

• Plugin version: 1.34

• OS: docker image based on jenkins/jenkins:lts

Description

If jobs section is present in jenkins.yaml, configuration reload fails, both via UI and groovy script. Jobs config works without any issues on init, but fails on reload. CASC_JENKINS_CONFIG is set to url.

Config example:

jobs:
  - script: >
      folder('xxx')

Error: groovy.lang.MissingMethodException: No signature of method: javaposse.jobdsl.plugin.JenkinsDslScriptLoader.customizeCompilerConfiguration() is applicable for argument types: (org.codehaus.groovy.control.CompilerConfiguration) values: [org.codehaus.groovy.control.CompilerConfiguration@67233c11]

Full trace: https://pastebin.com/0A2Mtz8z

[tbondarchuk]

To be honest, that page is quite lacking some important details. Like example of Jenkins CLI command or mention that only system groovy script will work… Should I maybe just create PR for that? 😃

I was able to find the root of this issue: forgot to remove load('reload.groovy') step from test job created by jobdsl 🤦🏻‍♂️ so seed job and reload job were working correctly but then test job was built by branch indexing and breaking jobdsl plugin…

Conclusion: using load pipeline step to run casc reload groovy command effectively breaks jobdsl plugin. Guess it’s a lack of permissions, but quite weird that it’s affecting jobdsl plugin in such way.

P.S. Maybe it will be useful for someone, my configs for casc reload:

jobdsl for reload job:

job('casc-reload') {
    steps {
        systemGroovyCommand("""
            import io.jenkins.plugins.casc.ConfigurationAsCode;
            ConfigurationAsCode.get().configure()
        """.stripIndent()) {
            sandbox(true)
        }
    }
}

declarative pipeline step to trigger reload:

build('casc-reload')

required permissions in casc:

  scriptApproval:
    approvedSignatures:
      - 'staticMethod io.jenkins.plugins.casc.ConfigurationAsCode get'
      - 'method io.jenkins.plugins.casc.ConfigurationAsCode configure'

[hak33m16]

Reloading JCasC is a system level operation. Allowing that from declarative pipeline risks all sorts of security mischief. I would not expect it to be allowed from declarative pipeline any more than I would expect that declarative pipeline would ever be allowed to change the system security realm.

Do you have any recommendations on how to automatically reload it securely then?

I think this is all really just working around the fact that JCaC offers no native way to automatically sync configuration from an external (preferably private) repository. The lack of that makes it largely useless IMO, because users have to, each time they make changes, go to the JCasC page and point it to the correct location to pull configuration from. And from looking, I couldn’t personally find a way to POST the JCasC in any officially documented way. Paired with the difficulty involved in figuring out what to put in there in the first place, it hardly feels worth the effort of using

Maybe this rant would be best suited to exist in a separate feature request for JCasC, or someone could point out to my why/how the suggestion is insecure