As designed. You get the ability to replay builds if you have the ability to reconfigure the job. If you do not want some people to change the Pipeline script, do not let them reconfigure the job.

I understand that from the security model's perspective you provide an option here. While that is correct, I think there two valid considerations to mention explicitly with regards to the original request both revolving around the changing role of Jenkins in CI as integration with external systems becomes stronger and more automated checks happen.

The first is that with Jenkinsfiles and builds as code, we, as users, are largely shifting the security control over the build process away from Jenkins to our SCM solutions (ex. GitHub).  When we build out processes and protections in that system to protect the Jenkinsfile and allow automated reporting of the build status control other workflows (since we trust the Jenkinsfile).  It can be alarming to discover that the SCM controls can completely be bypassed with the "Replay" feature on Jenkins which trivially let peoples people bypass all those checks since it allows edits.  Needing block all access to job configuration options to disable this "problematic" feature really sounds like a lot of administrative hassle making exceptions for when people really do need to just configure a job, I think this could be a good reason to make it a separate security option.

The next is really an appeal to consider the many users that are likely operating in a more security context. I am sure I'm not alone in using Jenkins in a relatively controlled corporate environment, everyone who has access to it is a "trusted" member of the team.  Many in such an environment would generally not consider it worth the cost to fully harden the CI system.  If we can make it easy to do the "right" we are not likely to have any issues; so long as it is working most users don't care enough to put in the effort to realize where the risks are.  The users that do realize the risk are not likely to be motivated to put in the effort to exploit them, and those that would want to exploit something (we really shouldn't have any of these) are likely the ones that would be really hard to stop.  Where this re-play with edits feature comes it is that it makes a "dangerous" option so easy that the first class of users that just want to use the system are likely to use it without realizing it is problematic, thus like the original request, it would be nice if we could just blanket disable this on a box.

From pure information security standpoint, if that is the only model you are considering, I understand that is horrible and there are all sorts of flaws.  When you consider the social environment and things like the cost of security vs convenience, being able to disable this particular enhancement would be valuable.

You can always use Extension Filter or simple Groovy hooks to remove features you do not want from your installation for whatever reason. I see nothing structurally inappropriate about Replay that would merit a UI option. It is just a tool to help you experiment with script changes before committing them to SCM—something you would otherwise do (with less auditability and more risk) by temporarily changing the job configuration to an inline script, copying and pasting text from SCM, running the build, then reverting the configuration immediately afterwards.

Hi jglick,

your suggestion to use Extension Filter sounds great, unfortunately I didn't manage what exactly the  class and the context for Replay Extension.

I tried several things, and also this: 

but it didn't work for me. Do you know what should I fill ? it will be really appreciated.

also if you can explain this sentence "Simple Groovy hooks to remove features" ? I'm using Jenkins and I never heard about it.

BR,

Adir Atias.

Hello,

we are also interested in this. We have very similar issues as described. We use Jenkins for CI/CD and pipeline provides guarantees like "only deploy the master branch" and one can only merge approved pull requests to the master branch. Now "replay" breaks the guarantees of four-eye principle.

We would love to keep the option to configure a job while disabling the replay.

It would be helpful to know how more about the options mentioned - the extension filter or the groovy hooks.