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.

ondrejburkert so, deny Job/Configure permission to non-admins.

I am not going to waste time developing/documenting customizations. Someone who is interested could write a plugin offering a /configureSecurity/ checkbox with a clear warning about why it is not offering actual defenses but merely making a (less auditable!) method of abuse very slightly less convenient.

jglick true, the fact that the person can configure the job allows them to do whatever already... Thanks for clarifying.

I have users who do not have Job/Configure, cannot access the job configuration, but can use Replay. Is there some other permission which grants this? Should this ticket be re-opened?

benlangfeld there is a Run/Replay permission that is normally implied by Job/Configure but can be independently granted; perhaps whoever set up authorization did so.

jglick I havn't granted that permission either. There must be some other in this set that permits replays.

benlangfeld it is either a bug or a misconfiguration. Better to file as a separate (but Link’d) issue with complete, self-contained steps to reproduce from scratch.

jglick I'm having the same issue. I'd like to prevent "replay" option on my pipelines but any user with "Job - Build" right also have the replay right. (bellow is a screenshot of their rights. In the global config the only permission they have is the global Read permission which is mandatory to access Jenkins UI) :

I'm having the same issue as larkoie user with `replay` option. It turns off only if disable `Build` permission
Jenkins: 2.204.1
Matrix Authorization Strategy Plugin: 2.5

Recreate:
jenkins 2.204.1 
and also tested on 2.190.1
1) install jenkins with plugins: 
workflow-aggregator:2.6
matrix-auth:2.5
2) create new user
3) change authorization type to `Project-based Matrix Authorization Strategy`
4) Enable overall/Read
for Authenticated Users

5) Create job 'pipeline' type and enable `Enable project-based security`
set Do not inherit and grant permissions 
Job/Build, Job/Read 
6) Run job 
7) login from created user from step 2 and run replay

Seems like it working but not hiding button on left panel and part of menu 

With enable Replay (button replay active)

With disable Replay same job (button replay active)

+1 to disable this button. I had deny the use of reply but it continue to propose in the build to developers that use it

I'd like to chime in and say this is a very serious security flaw.  It is extremely surprising to me that it is impossible to allow users to build Jenkins (Pipeline) jobs without also allowing them to modify jobs at will.

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.

We do not test changes like this.  We have our users run a 'dev' instance of Jenkins locally w/ their own credentials (this is all automated with tooling that sets it up for them).  Users can only run what their credentials allow, and the jobs have checks for 'dev' mode to skip some steps like publishing artifacts (or publishing to alternate locations).

Our 'prod' Jenkins instances are never changed by any users (including us who administer them).  We use the Netflix Job DSL, JCasC, and init.groovy.d scripts to configure everything without manual intervention.  Users are never allowed to modify the job configuration on the live 'prod' Jenkins instance.

From our perspective, this is a gigantic security hole.  A user just brought to my attention that users can bypass all of the Jenkins security by using the 'Replay' feature.  Any user who has access to build a job could simply use Replay to dump all of the credentials the job has access to and send them to an s3 bucket if they wanted, with little to no record of that happening inside the system.

I just want to bump the priority a bit since this is a huge security red flag.  We should be able to let users build a job without being able to alter a job.  The fact that this works with only the 'Build' permission is mind-boggling to me.  Users should be required to have at minimum the 'Configure' permission to change the content of a job and run it.

It's difficult to secure a system like this but I believe fixing this security hole would help a lot.  Thank you for your time, I really appreciate all the hard work the Jenkins team does.

We should be able to let users build a job without being able to alter a job.

Perfectly normal. Grant them Build and not Configure. Then they can rebuild (unmodified) but not replay.

Thanks so much Jesse, I recognize that I made a mistake in my configuration.  Disabling the 'Replay' permission in Matrix auth allows users to use the 'Replay' button but does NOT allow them to modify the contents of the Pipeline, which in effect causes it to work like a standard 'Rebuild'.  That is perfect and solves the apparent security issue (at least from the UI side, I haven't done any investigation to see if the API endpoint would allow you to send a modified script).

Thanks again for your quick response and your help.  Take care.

To anyone else encountering this issue, you can solve it by ensuring the 'Replay' permission is not enabled for your users/groups you don't want to have the permission.  The users must not have 'Configure' permission or they will automatically have 'Replay' permission, which makes sense since a user who can modify the job can already change the job configuration.  If users are able to change the Pipeline definition when clicking 'Replay', you have your permissions set up incorrectly so start there.

I spent some time in the Groovy Script console but was not able to make any headway in either removing the 'Replay' actions or modifying the classes to completely disable 'Replay' (since Groovy cannot modify Java classes via the metaClass).  Removing the UI element via Groovy (init.groovy.d or Script Console) would be a nice-to-have but it isn't really important.

Since I stumbled over this as well (cf. my comment for JENKINS-63080):

• I think it would be less confusing, if "Replay" button would just not show up, if the user has "Job/Build" permission, but not "Run/Replay" (even though it behaves the like "Build" job due to missing edit script possibility)

Possibly it would suffice for https://github.com/jenkinsci/workflow-cps-plugin/blob/f522e783e917bc0aa0513a29684285b710163905/src/main/java/org/jenkinsci/plugins/workflow/cps/replay/ReplayAction.java#L99 to check isEnabled() and display as either Replay or Rebuild accordingly?

Rebuild and replay (rerun) are two different things therefore it would be even more confusing than what is now.

For dynamic pipelines (like k8s backend) replay almost never works while rebuild is fine.

Thanks for your fast feedback!

Ad "Rebuild" (What?): Frankly I have not even heard of the "Rebuild" functionality so far – and I claim to be (non-core-developing) Jenkins (power) user; on the other hand I am every now and then very, very happy about the "Replay" feature (e.g. when quickly doing an experiment, or when developing/changing a pipeline or the pipeline library). I even dare to claim "Rebuild" feature is NOT part of the official Jenkins (pipeline) documentation, while (obviously "Build") and "Replay" are (see https://www.jenkins.io/doc/book/pipeline/development/#replay).
Actually I don't want less experienced or non-power-users to be able to use or even see either of those two ("Rebuild" and "Replay"). (Because "Rebuild" is IMHO nothing "regular"/"normal" or something for normal i.e. non-power users; or actually a CI/CD anti-pattern, cf. this "funny" story: when I joined my current company, the state of CI was so unstable/untrusted/brittle, that in case any build failed, for developers it was the most natural and first thing to just re-trigger it without thinking err I of course meant hesitating )

I therefore was tempted to write: There is no need for "Rebuild". Power-users have "Replay" and thus "Rebuild". Because "Rebuild" is a "Replay" without changing anything in the script editor.
And now matt_kucia surprises me with "replay almost never works while rebuild is fine":

• Based on that comment there would be the need for this feature and there are people that are used to that and don't want to miss that.

Summary

• I must admit to still learn new things as a (non-core-developing) Jenkins (power) user after years of using. And I am still not sure to have understood everything around "Build"/"Replay"/"Rebuild" correctly...
• Based on matt_kucia's comment I guess/assume that other users really need and don't want to loose this "Rebuild" feature.
  • Just once more (to really annoy you?): Is "Rebuild" really needed? Or is "Replay" (as documented) sufficient?
    • If not, please get rid of the "Replay" button in case the user does not have "Replay" permission... *pray*
• => Then (and really only then when "Rebuild" is really needed) I personally think jglick's compromise proposal is the way to go

Indeed rebuild is not part of Jenkins Core. It's a convenience plugin: https://plugins.jenkins.io/rebuild/

Or a concept of triggering build with the same parameters as previous one.

matt_kucia Thanks a lot for the clarification!

I did not know that plugin and we are not using it – in fact it is not even installed.
And the workflow-cps-plugin code is independent of that one (and a core pipeline plugin), so I guess that this ticket, as well as jglick proposal are also completely independent of that "Rebuild" plugin. Unless the plugin depends (internally) on "workflow-cps-plugin" (via a non-official API, which I would not hope)?

Updated naive summary
To not just avoid, but prevent confusion (cf. JENKINS-50855, JENKINS-47339, JENKINS-63080, ...):

• Because "Replay" is "Replay" and for power-users (only) => Please get rid of the "Replay" button in case the user does not have "Replay" permission... *pray*

(Alternatively) Oh no, based on https://github.com/jenkinsci/workflow-cps-plugin/pull/187 I fear think you really want to keep it (as "Rebuild") => Please apply jglick's compromise proposal as it is IMHO definitely better than the current situation by avoiding the confusion... and seemingly very, very easy (thanks Jesse)

Thank you all and sorry for my spamming..

I am a bit confused. Doesn't the "new pipeline rerun" skip successful stages? I had a hard time communicating not to use "replay" button on Blue Ocean. If doing so the builds fail for me with missing resources. This isn't consistent and I do not know minimal replication steps for that problem. I have dynamic agents on k8s and workspaces are ephemeral.

The perfect behaviour for my use cases (I do acknowledge that my configuration does not necessary consider others) would be that the Blue Ocean button behaviour is identical to rebuild plugin behaviour.

btw We have 3 terms here: Rebuild, Rerun and Replay.

I believe Rerun and Replay are the same and used interchangeably in Jenkins code.

Rebuild is equivalent to "Build with parameters" with parameters picked from another, completed job run. There is a rebuild button in old UI added by the non-core plugin.

Please consider my messages as user feedback, I am not trying to push anything here. I appreciate your effort to make Jenkins better.

For Declarative Pipeline only, there is a distinct ability to restart a build from a specified stage. It is similar to Rebuild (i.e., Replay without permission to modify scripts) but sets a special flag interpreted by the Declarative system to skip earlier stages.

Oh and in case you were not confused enough today, CloudBees CI includes a checkpoint step which offers roughly analogous functionality to Scripted (but not Declarative) Pipelines.

*LOL* Thanks Jesse (especially for your humour): frankly, the confusion was certainly enough for me, so I waited till now before adding another (semi-important) comment

=> I trust you to find an acceptable solution – that is at least slightly better than the current confusing situation

• If "Rebuild" is supposed to stay, then your button renaming proposal according to https://issues.jenkins.io/browse/JENKINS-39874?focusedCommentId=405532&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-405532 is perfectly OK with me; I assume this applies to classic UI AND Blue Ocean UI...

JENKINS-50855 pertains only to the “classic” UI. Blue Ocean is unrelated.

I have another use case that might or might not be common, but it certainly makes me want to have an ability to disable this feature. Not just on the level of user access - just disable it period.

I have a groovy lib that generates a pipeline dsl dynamically and then evaluates it. It is being generated in chunks that are evaluated separately. When my team (who unlike my users - are jenkins admins by design having full access to everything) click Replay - due to the dynamic dsl generation they see 10+ text boxes with parts of the dsl. Because at Replay this dsl getting called outside of the proper context - it just fails. Replay just doesn't work for me and creating more issues than it solves. Not all of my team understands the way groovy lib and CPS works in Jenkins - most of them just configure jobs and by coincidence have access to the Replay feature. I wish I could completely disable Replay for our prod Jenkins instance just because it is buggy for us in the library context.

I just wanted to add that "replay" is not equal to "rebuild" form the usage os shared libraries point of view:

• "replay build #XX" uses the same version of the shared library that was use during the first build of the build #XX
• "rebuild build XX" loads the shared libraries again: so with rebuild we get the latest version of a shared library

this behavior confuses our users for example in the following case:

1. we release pipeline code in form a shared library release
2. before the release of a shared library, the users were using version 1.0 ( tag stable) of the shared library
3. After the release the tag stables points to a different version (2.0 for example )
4. but a replay in this case is not loading version 2.0, and the users are still using the old version 1.0 ( sometimes with breaking changes )

therefore it would be good for us if we could disable the "replay" button completely (it shouldn't be visible) for normal users who have the "build" permission and no "configure" permission

Additionally, "replay" is not equal to "rebuild" for jobs that can take build arguments: the "replay" does not offer to change their values, and just uses what was specified in the replayed run.

If you had a typo in one of a dozen arguments, with Replay alone you have to schedule a new job (Build with Arguments) and copy-paste all those args and amend the one you got wrong the first time.

On a related side note: Woe on you if you are in the midst of developing a pipeline in a (hopefully local) Jenkins instance, replaying its iterations a few dozen times before you copy-paste successful stuff back to an editor, and need to change some build argument to test a codepath.

At the very least, it is confusing however to see two "Rebuild" buttons for under-privileged users, whereas ones allowed to edit the pipeline see "Rebuild" (from respective plugin) and "Replay" separately:

 
...and that in Blue Ocean the same action is known as a "Rerun"

Also, replay has "no idea what it is doing" in the context of shared library load calls (and the load calls themselves have a race condition https://issues.jenkins.io/browse/JENKINS-69224). We are using a shared library that handles every job out of 999+ and there the load step is called in some random place in Groovy. If I press Replay, then it lists all scripts numerically like Script1...N, but the thing is, they all come from nested parallel steps, so the order is not reproducible. If a user replays the job, the wrong override text is used for the wrong load step so we end up with random behavior.