I am using the Active Choice plugin to dynamically fill a combo box using some Jenkins global variables.
In the context of execution of Active Choice, I can’t seem to be able to access them the usual way using environment variables, so I had to use Jenkins.getInstance in the groovy.
It’s working fine, but requires me to approve ‘staticMethod jenkins.model.Jenkins getInstance’ signature, which I’d like to avoid.
I tried to move my groovy to a scriptlet, that I approved, but even then, approving the getinstance function was still necessary.
What would be the proper way of securing this piece of code ?
Normally, I would move this kind of code in a shared library, but I don’t think I can use them in the context of the Active Choice plugin.
On the other hand, if there’s a way to access Jenkins global variables without using the getinstance, I’d be glad to know
I approve all of MY OWN Active Choices code so this is never a problem for me. In your case depending, on who else is writing AC or Groovy scriptlet code, you are probably right to be careful. Nonetheless, you can get your ‘global’ variables in another way by faking them in a simple key-value properties file you can serve from userContent. Just write a simple Groovy script that reads the properties from the ‘fake-globals’ properties file and populates your active choices. This will not require you to approve the dangerous signature. I hope this gives you some additional ideas.
While I do approve my own AC, approving the signature for the getInstance() method would make it accessible to all declarative pipeline scripts. This includes individuals with access to the Replay feature who can modify their Groovy scripts, potentially through unauthorized means. Therefore, I prefer not to approve this type of signature.
I appreciate your suggestion and will consider it if no other solutions are found.
