Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27134

Permission for input approval, or choice of Jenkins-specific group as submitter

      Currently the input step allows you to specify a submitter, which may be a user ID or an external group ("granted authority"). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees.

      Arguably the more natural approach would be for InputStep to define a new permission, "approve flow", which would be checked on the WorkflowRun (can use PermissionScope.RUN). Thus rather than specifying a submitter for a particular step you would just ensure there was an RBAC group defined on the flow job (or its folder, etc.) which granted that permission and included the people you want. Then no reference need be made to any particular AuthorizationStrategy at all; this behavior would just follow from the Jenkins authorization model.

      If defined, submitter would still be consulted in case the approving user lacked the new permission. There is a potential compatibility issue in case submitter was not defined; today that means that any user (even anonymous) can approve the flow, whereas we would want the new permission to be enforced. Unfortunately Jenkins offers no way to mark a newly introduced Permission as "granted until explicitly denied", except via system property hacks; see comment in JENKINS-17200. Lacking that, the only option is to break compatibility and say that existing input steps without submitter will now reject random users from approving. The new permission could be implied by, for example, Item.CONFIGURE to minimize the impact—approval by the person who wrote the flow would still be guaranteed to work.

          [JENKINS-27134] Permission for input approval, or choice of Jenkins-specific group as submitter

          Jesse Glick added a comment -

          actually defining it in core would prevent uptake from plugins

          stephenconnolly proposes some mechanism TBD whereby the API could be defined in core for the long term, with a copy in some plugin permitting it to be used in the near term without a new core dependency. This has been done in the past for certain other APIs, though it can be tricky depending on the case.

          Jesse Glick added a comment - actually defining it in core would prevent uptake from plugins stephenconnolly proposes some mechanism TBD whereby the API could be defined in core for the long term, with a copy in some plugin permitting it to be used in the near term without a new core dependency. This has been done in the past for certain other APIs, though it can be tricky depending on the case.

          Karl Shultz added a comment - - edited

          This can look like a pretty bad bug if you don't know about it. Because the input step appears to ignore Jenkins-level permissions, but still allows you to use them in the definition of the step, this can hang an entire build.

          inputStepVideo.webm

          Karl Shultz added a comment - - edited This can look like a pretty bad bug if you don't know about it. Because the input step appears to ignore Jenkins-level permissions, but still allows you to use them in the definition of the step, this can hang an entire build. inputStepVideo.webm

          Jesse Glick added a comment -

          kshultz I am not sure what that video is showing. What is this “put your admin password please”? Not a message I recognize. Steps to reproduce from scratch?

          Jesse Glick added a comment - kshultz I am not sure what that video is showing. What is this “put your admin password please”? Not a message I recognize. Steps to reproduce from scratch?

          Karl Shultz added a comment - - edited

          There are two ways to show this. the first is to demonstrate that the password provided for a valid Jenkins user seems to get ignored.

          1. Create a Pipeline job, using the following script:

          stage ('inputStage') {
              input id: 'CustomID', 
              message: 'Message Body', 
              ok: 'OK', 
              parameters: [password(defaultValue: 'admin', description: 'Password Parameter', name: 'admin')], 
              // Below in the submitter field I've got the correct 
              // username of admin. But I can provide any string 
              // as the password for admin, and the pipeline will 
              // move on to the next stage.
              submitter: 'admin', 
              submitterParameter: 'approvingSubmitter'
          }
          
          stage ('After Password') {
              echo 'I should only see this if I put in the right password'
          }

          2. Build this job.

          3. Enter an invalid password for the user supplied in 'submitter' which in this case is 'admin'

          4. That stage of the pipeline will complete, and you'll move on to the next stage, even though the password you provided is known to be wrong.

          The second problem to demonstrate is by setting the 'submitter' setting to something that's not a real Jenkins user, like "nonsenseThing" in the below:

          stage ('inputStage') {
              input id: 'CustomID', 
              message: 'Message Body', 
              ok: 'OK', 
              parameters: [password(defaultValue: 'admin', description: 'Password Parameter', name: 'admin')], 
              // Below in the submitter field I've got a bogus 
              // user name of nonsenseThing set. When I try it this 
              // way, the job will hang.
              submitter: 'nonsenseThing', 
              submitterParameter: 'approvingSubmitter'
          }
          
          stage ('After Password') {
              echo 'I should only see this if I put in the right password'
          }
          

          Karl Shultz added a comment - - edited There are two ways to show this. the first is to demonstrate that the password provided for a valid Jenkins user seems to get ignored. 1. Create a Pipeline job, using the following script: stage ('inputStage') { input id: 'CustomID', message: 'Message Body', ok: 'OK', parameters: [password(defaultValue: 'admin', description: 'Password Parameter', name: 'admin')], // Below in the submitter field I've got the correct // username of admin. But I can provide any string // as the password for admin, and the pipeline will // move on to the next stage. submitter: 'admin', submitterParameter: 'approvingSubmitter' } stage ('After Password') { echo 'I should only see this if I put in the right password' } 2. Build this job. 3. Enter an invalid password for the user supplied in 'submitter' which in this case is 'admin' 4. That stage of the pipeline will complete, and you'll move on to the next stage, even though the password you provided is known to be wrong. The second problem to demonstrate is by setting the 'submitter' setting to something that's not a real Jenkins user, like "nonsenseThing" in the below: stage ('inputStage') { input id: 'CustomID', message: 'Message Body', ok: 'OK', parameters: [password(defaultValue: 'admin', description: 'Password Parameter', name: 'admin')], // Below in the submitter field I've got a bogus // user name of nonsenseThing set. When I try it this // way, the job will hang. submitter: 'nonsenseThing', submitterParameter: 'approvingSubmitter' } stage ('After Password') { echo 'I should only see this if I put in the right password' }

          Jesse Glick added a comment -

          The first script makes no sense. You asked for some text from a password field, and you got it, and then threw away the return value. Nothing to do with Jenkins user accounts. There is no Pipeline feature to ask a user to log in with a password. Nor should there be: if they can get to the input request page, clearly they are already logged in.

          The second script does not demonstrate a bug that I can see, or perhaps I am not understanding your complaint. You requested that the input only be approved by a user named nonsenseThing or who is in a group by that name. Since the user attempting to submit is neither, Jenkins refuses to accept the submission.

          Again, this issue is about an RFE: being able to use something like a role or other Jenkins-defined group, rather than an external (e.g., LDAP) group, in the submitter parameter. Anything else you are trying to do is probably unrelated.

          Jesse Glick added a comment - The first script makes no sense. You asked for some text from a password field, and you got it, and then threw away the return value. Nothing to do with Jenkins user accounts. There is no Pipeline feature to ask a user to log in with a password. Nor should there be: if they can get to the input request page, clearly they are already logged in. The second script does not demonstrate a bug that I can see, or perhaps I am not understanding your complaint. You requested that the input only be approved by a user named nonsenseThing or who is in a group by that name. Since the user attempting to submit is neither, Jenkins refuses to accept the submission. Again, this issue is about an RFE: being able to use something like a role or other Jenkins-defined group, rather than an external (e.g., LDAP) group, in the submitter parameter. Anything else you are trying to do is probably unrelated.

          Sam Van Oort added a comment -

          jglick I explicitly asked kshultz to leave a note here about some oddities he saw when testing my features – I think maybe there may be some confusion here, but the crux of the matter is that even admin permissions aren't enough to grant approval for an input step (even though you can rewrite the job totally with those permissions). 

          Feels like there was some miscommunication here, but in general this is just another facet of the feature request – adding integration of Jenkins permissions and roles into the input step approval process.

          Sam Van Oort added a comment - jglick I explicitly asked kshultz to leave a note here about some oddities he saw when testing my features – I think maybe there may be some confusion here, but the crux of the matter is that even admin permissions aren't enough to grant approval for an input step (even though you can rewrite the job totally with those permissions).  Feels like there was some miscommunication here, but in general this is just another facet of the feature request – adding integration of Jenkins permissions and roles into the input step approval process.

          Jesse Glick added a comment -

          Better discussed in JENKINS-29346.

          Jesse Glick added a comment - Better discussed in  JENKINS-29346 .

          sai krishna added a comment - - edited

          kshultz I am looking for this one. Thank you for your information. But how can we validate the password of that particular user ? and what about the abort restrictions ?

          sai krishna added a comment - - edited kshultz I am looking for this one. Thank you for your information. But how can we validate the password of that particular user ? and what about the abort restrictions ?

          Jesse Glick added a comment -

          saikrishna sounds like questions for the Jenkins user list.

          Jesse Glick added a comment - saikrishna sounds like questions for the Jenkins user list.

          Jean-Pierre Fouche added a comment - - edited

          Please would you be able to address the issue with RBAC stated in the description?

          i.e. 

          "Currently the input step allows you to specify a submitter, which may be a user ID or an external group ("granted authority"). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees."

          I find that the 'submitter' attribute does not work on the input step.  We are using Keycloak role-based AuthorizationStrategy.  (Our code for the input step has not changed, but we recently changed Jenkins setup from a matrix based authorisation strategy to Keycloak).

           

          Code below.  Expected result is that if there is a user in  Keycloak, it should verify that the logged in user matches.  Similarly, if there is a group in Keycloak, the logged in user should be a member of the specified group.

          isApproved = input(
                  id: 'someId',
                  message: 'Approve?',
                  submitter: 'someuser', // <== 'does not query Keycloak; ignores this 
                   parameters: [choice(
                          choices: ['No', 'Yes'],
                          description: 'some description',
                          name: 'some name')]
          ) == 'Yes'
          

           

           

          Jean-Pierre Fouche added a comment - - edited Please would you be able to address the issue with RBAC stated in the description? i.e.  "Currently the input step allows you to specify a submitter, which may be a user ID or an external group (" granted authority "). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees." I find that the 'submitter' attribute does not work on the input step.  We are using Keycloak role-based AuthorizationStrategy.  (Our code for the input step has not changed, but we recently changed Jenkins setup from a matrix based authorisation strategy to Keycloak).   Code below.  Expected result is that if there is a user in  Keycloak, it should verify that the logged in user matches.  Similarly, if there is a group in Keycloak, the logged in user should be a member of the specified group. isApproved = input( id: 'someId' , message: 'Approve?' , submitter: 'someuser' , // <== 'does not query Keycloak; ignores this parameters: [choice( choices: [ 'No' , 'Yes' ], description: 'some description' , name: 'some name' )] ) == 'Yes'    

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            14 Vote for this issue
            Watchers:
            23 Start watching this issue

              Created:
              Updated: