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

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

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            virasana 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'
            

             

             

            Show
            virasana 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'    
            Hide
            jglick Jesse Glick added a comment -

            sai krishna sounds like questions for the Jenkins user list.

            Show
            jglick Jesse Glick added a comment - sai krishna sounds like questions for the Jenkins user list.
            Hide
            saikrishna sai krishna added a comment - - edited

            Karl Shultz 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 ?

            Show
            saikrishna sai krishna added a comment - - edited Karl Shultz 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 ?
            Hide
            jglick Jesse Glick added a comment -

            Better discussed in JENKINS-29346.

            Show
            jglick Jesse Glick added a comment - Better discussed in  JENKINS-29346 .
            Hide
            svanoort Sam Van Oort added a comment -

            Jesse Glick I explicitly asked Karl Shultz 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.

            Show
            svanoort Sam Van Oort added a comment - Jesse Glick I explicitly asked Karl Shultz 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.

              People

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

                Dates

                • Created:
                  Updated: